Дизайн секции как проверка навыков проектирования систем на собеседованиях

В конце октября я выступил в очередной раз на конференции ArchDays 2021 с темой, вынесенной в название доклада. Для меня это выступление было важным, так как я в Tinkoff курирую эту секцию по проектированию распределенных систем и часто отвечаю на вопросы кандидатов о том, зачем мы ее проводим и какие выводы на основе результатов прохождения делаем.

Надеюсь, что эта статья с расшифровкой выступления ответит не только на эти вопросы, но и расскажет как выглядит такое собеседование и как к нему подготовиться.

Update:

Я проводил такой тип интервью на C++ Russia 2022 и ArchDays 2022. Плюс я подробнее рассказывал в моих последующих статьях:

— как мы оцениваем прохождение собеседования
— как к нему подготовиться.

Рис. “Заглавный слайд”

А для тех, кто любит смотреть выступления, вот ссылка на запись.

Ну и начнем мы с того, что я расскажу как у нас выглядит процесс найма условного бэкенд разработчика и где там место дизайн-секции.

Рис. “Как выглядит найм”

Наш процесс собеседования выстроен с фокусом на масштабирование. Это проявляется в том, что он разделен на отдельные этапы, которые проводятся максимально независимо. Все начинается с сорсеров (от англ. source), которые занимаются поиском кандидатов по определенным источникам (hh, github, linkedin, …).

Дальше найденные кандидаты попадают к рекрутерам, которые проводят предварительное интервью. В итоге, у рекрутера появляется понимание насчет самооценки кандидата, софтовых навыках, опыте кандидата и наличии желания сменить работу, например, пройдя наши этапы технического интервью.

Для бэкенд разработчиков у нас есть три технических этапа:

— computer science про структуры данных и алгоритмы
— языковая секция, в которой проверяется знание основного языка и экосистемы вокруг него
— дизайн распределенных систем

Конечно дизайнить системы мы просим не всех, а только тех, кто претендует на senior позиции. Чуть позже я расскажу в чем наша мотивация, но сейчас стоит отметить, что классные кандидаты дальше общаются с командой и это fit interview. Если все хорошо, то кандидат получает оффер. Вся схема отображена на рисунке ниже.

Рис. “Диаграмма уровня кандидата и стадий найма”

Теперь когда мы знаем как выстроен весь процесс найма, нам стоит вернуться к вопросу дизайн секций и начать с целеполагания, а именно с того, чтобы ответить на вопрос

Рис. “Зачем мы проверяем навыки дизайна систем?”

И здесь ответ очень простой

• Мы быстро растем по количеству клиентов — повышается нагрузка на существующие системы, они становятся все более высоконагруженными
• У нас появляются новые бизнес-вертикали как внутри России, так и за ее пределами — нам нужны люди, которые могут брать на себя ответственность за части продукта, а не просто писать код по постановке спущенной сверху какими-то архитекторами
• Наши продукты формируют экосистему — это значит, что они должны быть интегрированы между собой, причем интеграция не должна мешать продуктам развиваться с нужной скоростью
• Вслед за ростом числа клиентов и продуктов у нас растет штат — это приводит к тому, что монолитные команды делятся на автономные stream-aligned команды, в которых требования к компетенциям участников возрастают
• Мы идем в сторону децентрализации принятия архитектурных решений — инженеры в командах должны сами уметь в проектирование систем

Подробнее про наш подход к архитектуре можно прочитать/посмотреть в моей статье “Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения”.

Но это полезно не только нам как компании — польза от такого собеседования двухсторонняя, поэтому есть смысл обсудить

Рис. “Чем это полезно кандидату”

Но польза отличается в зависимости от результатов прохождения дизайн секции:

• Если дизайн-секция пройдена круто, то мы можем предложить более интересные условия как по уровню дохода, так и по уровню интересности задач
• Если дизайн-секция пройдена нормально, то мы можем предложить кандидату команду, где он сможет расти на практических задачах под чутким присмотром коллег
• Если дизайн-секция не пройдена, то мы даем кандидату персонализированную обратную связь, в которой отмечаем что стоит подтянуть и где это можно изучить

Теперь стоит перейти к тому

Рис. “Как выглядит дизайн секция”

Я поделил дизайн-секцию на части, которые расположены в порядке их выполнения. Все они представлены на рисунке ниже

Рис. “Основные шаги собеседования”

Все начинается с первого этапа, на котором интервьюер сообщает название задачи, дает дополнительный контекст и формулирует основные функциональные и нефункциональные требования. Дальше пульт управления собеседованием переходит к кандидату и именно он ведет собеседование (если может).

Второй шаг — это формализация задачи, в рамках которой кандидат должен задать вопросы интервьюеру, например, уточнить что именно должна позволять делать система. Важно определить, а что является ключевым для системы, например:

— high availability (высокая доступность)
— data consistency (консистентность данных)
— high throughput
— scalability
— auditability

В общем и целом, тут могут быть любые архитектурные характеристики, многие из которых на английском языке оканчиваются на ilities. Подробнее про их важность я рассказывал в статье и выступлении “Эволюционная архитектура на практике”.

Кроме этого надо задать вопросы, которые позволят понять нагрузку на систему: сколько пользователей будет, как будет выглядеть нагрузка от них (количество запросов), сколько данных придется хранить и так далее. Важно не просто задать эти вопросы подряд, а подобрать их исходя из контекста задачи и, задав часть вопросов, сформулировать некоторые гипотезы о конкретных важных для системы числах. Именно эти данные нам потребуется использовать для проработки вопросов сайзинга системы.

Третьим этапом можно уже начинать проектировать систему и на этом шаге важно зафиксировать границы системы, какие сценарии мы должны реализовать и какое публичное API будет предоставлять система. На этом этапе система для нас представляется черным ящиком, но мы уже знаем что этот черный ящик обещает своим пользователям:) В общем и целом на этом этапе мы фактически строим System Context Diagram из C4 Model

A System Context diagram provides a starting point, showing how the software system in scope fits into the world around it.

Четвертый этап самый интересный, так как именно на нем итеративно проектируется система. На этом этапе важно проработать потоки данных:

— как приходит запрос в нашу систему
— что мы с ним делаем — сохраняем в базу данных, закидываем в очередь, отправляем в /dev/null
— и так далее

По мере того, как мы прорабатываем поток данных у нас появляются компоненты системы, которые выполняют какие-то функции, которые требуются для реализации желаемого сценария.

Лучшая стратегия на данном этапе начинать прорабатывать happy path сценариев нашей системы, а потом возвращаться к exceptional flows и пытаться учесть их. Важно также не забывать про нефункциональные требования, например, такие, что мы не можем терять задачи пользователя и должны их выполнить за какое-то ограниченное время.

Именно на этом этапе важно проработать сайзинг системы на концептуальном уровне, то есть что систему при необходимости получится отмасштабировать под планируемые нагрузки. Например, стоит проверить, что самые нагруженные части горизонтально масштабируются и мы знаем как это сделать.

Теперь мы знаем как выглядит процесс решения задачи и стоит посмотреть на него вживую на примере конкретного решения задачи

Рис. “Как выглядит типовая задача”

Давайте пройдемся по шагам. И начнем с нулевого, который про знакомство с инструментом, в котором происходит совместное проектирование решения. Мы в Tinkoff используем разные сервисы для рисования диаграмм. Обычно интервьюер показывает интерфейс системы и рассказывает какие иконки стоит использовать, а также как соединять элементы между собой. Кстати, первые несколько шагов приведены на изображении ниже.

Рис. “Пример задачки”

Следующий шаг — это постановка задачи. Интервьюер рассказывает ее голосом и одновременно добавляет требования на доску, чтобы они всегда были перед глазами у кандидата и к ним было легко вернуться и проверить насколько решение соответствует ожиданиям.

После рассказа о требованиях мяч переходит к кандидату и он может уточнить по задаче все что осталось непонятным. Например, он может задать вопросы, которые относятся к планируемой нагрузке на систему, так как эти моменты зачастую драматически влияют на то, какая концептуальная схема получится в итоге. Ответы на эти вопросы обычно классно зафиксировать рядом с начальными требованиями, потому что они нам потребуются в дальнейшем. Потом наступает время рисовать границы системы, ее клиентов, публичный API. На этом мы прощаемся с примером задачи и переходим к следующей части, в которой обсуждаем

Рис. “Как мы оцениваем кандидата”

Для оценки кандидата хорошо бы иметь некоторые критерии, которые позволяют взвешенно подойти к вопросу продемонстрированных им компетенций. Для этого логично использовать матрицу, которую я представил на рисунке ниже.

Рис. “Критерии оценки кандидатов”

Важно, что эти критерии частично пересекаются с шагами прохождения секции дизайна, поэтому логику оценки можно понять из описания этапов прохождения выше. Только два последних пункта специфичны, поэтому посмотрим на них подробнее:

Читаемость получившейся схемы — здесь оценивается то, насколько итоговая схема получилась читаемой и содержащей основные моменты. От начинающего дизайнера ожидается, что его схема будет содержать валидный основной flow + концептуальные компоненты системы, exceptional flow и corner cases на диаграмме отсутствует, а для ее чтения нужны комментарии автора.

Дополнительные вопросы — обычно в этом пункте оцениваются те вопросы, которые удалось обсудить помимо основной задачи. Например, технический кругозор кандидата, когда несколько вариантов конкретной технологии могут быть использованы для решения задачи или какие-то моменты, которые расширяют задачу и делают ее более сложной. Обычно если дело дошло до содержательных дополнительных вопросов, то это хороший знак.

Понятное дело, что для каждого критерия есть свои требования для оценки уровня и схематично это представлено на рисунках ниже

Рис. “Уровни оценки по критериям”

Но в жизни редко бывает так, чтобы продемонстрированные компетенции были так четко выровнены по одному уровню. Обычно с реальным кандидатом все выглядит скорее так, как показано на рисунке ниже

Рис. “Общая оценка кандидата на примере конкретного профиля”

Давайте рассмотрим этот пример:

• Кандидат неплохо поработал над формализацией задачи, уточнил функциональные и нефункциональные требования и четко понял что от нашей системы ожидают
• Дальше он правильно прочертил границы системы, планируемые сценарии, которые требуется реализовать, и зафиксировал API, которое мы предоставляем
• После этого он хорошо понял и нарисовал процесс, включая happy path и exceptional flow, возможно с небольшими наводящими вопросами
• Дальше он неплохо задизайнил концептуальную схему и определился с моделями данных, которые ходят и хранятся внутри системы
• Вот с конкретными технологиями все пошло не так здорово — их он предложил, но взял просто из своего опыта без особого понимания насколько они хорошо подходят в контекст задачи
• Соответственно вопросы нагрузки тоже зашли не очень хорошо — сам он их не собрал, поэтому пришлось подсказать кандидату, что их требуется учесть. Но их учет был скорее ради галочки, чем реально что-то предусматривал
• Читаемость получившейся схемы вышла на уровне
• А секция дополнительных вопросов была посвящена вопросам про широту знаний в технологиях. Но широта знаний — это не сильная сторона кандидата.

Итого: у нас в этом примере получился кандидат, который умеет задавать правильные вопросы заказчику, умеет понять что входит в его систему и как она представлена наружу, может нарисовать flow автоматизируемого процесс и накидать концептуальную диаграмму. Все это относится к сильным сторонам, а вот к слабым сторонам можно отнести выбор реальной схемы и конкретных используемых технологий, неумение проектировать сервисы, которые должны держать умеренную нагрузку и узкий кругозор в технических вопросах.

По-моему мнению, такому человеку можно выдать уровень Middle в дизайне распределенных систем, отметив отдельно сильные и слабые стороны, а также выдав рекомендации по дальнейшему развитию самому сотруднику и его будущему руководителю.

Теперь мы добрались до самого конца статьи и пришло время дать

Рис. “Как научиться проектировать системы”

— Моя статья “System Design Interview и как к ним подготовиться”
— Книга “System Design Interview: An Insider’s Guide” и мой краткий обзор предлагаемого в ней фреймворка для прохождения интервью
— Моя статья «Как прокачаться в проектировании ПО — книги»
— Крутой ресурс «The System Design Primer»
— Курс Мартина Клеппмана «Distributed Systems»
— Курс «Essential Architecture»
— Можно посещать конференции, например
— →ArchDays
— →Highload
— →Hydra

А если вам вдруг стало интересно почитать подробнее про наши собеседования в Тинькофф, то можно познакомиться с более подробным описанием на нашем Github.