System Design Interview и как к ним подготовиться

Сегодня я выступал на нашем мероприятии в Рязани с обновленной версией своего доклада “Дизайн секции как проверка навыков проектирования систем на собеседованиях”. В этот раз я сделал упор на то, как подготовится к прохождению интервью. Для этого я детальнее объяснил как оно оценивается и привел материалы, которые мы используем для онбординга новых интервьюеров. По результатам выступления я решил написать краткую статью в продолжении предыдущей.

Update: Недавно я проводил публичное интервью по System Design на C++ Russia и в статье я привел ссылку на запись, а также рассказал как сам бы решал эту задачу, если бы у меня был час на ее решение.

Рис.1 “Заглавное изображение”

System Design Interview проводится для проверки навыка проектирования распределенных систем. Само собеседование носит открытый и свободный характер, поэтому требуются дополнительные усилия для правильной интерпретации результатов. В этой статье я попробую дать ответы на вопросы

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

Критерии оценки кандидатов

Мы смотрим на следующие моменты:

• Как кандидат формализовал задачу — если говорить кратко, то это про понимание того, какую систему надо спроектировать и какие к ней есть требования. Обычно мы в начальных условиях даем достаточно требований для базового понимания, но для того, чтобы не попасть впросак требуется ряд уточнений и вопросы кандидата очень показательны в этом плане
• Как кандидат понял и прочертил границы системы — а именно что входит и не входит в границы задачи. Характерной чертой хорошо выстроенных границ является понимание основных сценариев работы системы и четко формализованного API
• Как кандидат уловил основной поток работы нашей системы + отобразил через какие компоненты системы он проходит. В зависимости от типа задачи в автоматизируемом процессе может быть как закопано много сложности, так и наоборот почти никакой.
• Как кандидат проработал концептуальную схему. В моем мире концептуальная схема состоит из
  — классов кубиков, из которых состоит система (или Architecture Building Blocks (ABB) из TOGAF)
  — моделей данных, которые хранятся в этих кубиках и/или путешествуют между ними
• Как кандидат проработал реальную схему. По-факту, это выбор для каждого кубика конкретного представителя (или Solution Building Block (SBB) из TOGAF). Здесь кандидат может продемонстрировать крутой кругозор и умение аргументировать свои решения
• Когда выбраны конкретные кубики, то можно уже обсуждать то, как получившаяся схема учитывает вопросы масштабирования под нагрузку. Этот момент хорошо прорабатывают или практики, что многое видели в своей жизни, или теоретики, которые очень хорошо подкованы в проблемах распределенных и высоконагруженных систем
• В финале можно посмотреть на получившуюся схему и оценить насколько она читаема, то есть пригодна для передачи информации о спроектированной системе. Если без автора схема нечитаема, то это плохой знак.

Уровни оценок

Описанные выше моменты мы оцениваем по следующей шкале:

• Junior — этот уровень можно зачастую выбить просто обладая логическим мышлением и имея теоретический/практический опыт в разработке
• Middle — этот уровень уже требует некоторого опыта в проектировании (или вдумчивого штудирования всяких книг и курсов по System Design Interview)
• Senior — этот уровень требует большого опыта в проектировании, а зачастую и широкого кругозора
• Senior+ — этот уровень используется редко (мало таких умельцев) и показывает условно эталонный навык или умение в отдельном критерии

Интегральная оценка

Интегральная оценка выставляется на основании экспертной трактовки оценок по отдельным критериям. В статье про System Design Interview я рассказывал подробнее и приводил пример. Здесь поделюсь rule of thumb в плане выставления и чтения интегральных оценок:

• Junior — обладает хорошей логикой, может собрать решение, которое будет работать в случае happy path и не слишком высокой нагрузки. Человек сам проектировать не может. Может решать хорошо декомпозированные и специфицированные задачи обычно в рамках сервиса/модуля. Для роста требуется сильная команда вокруг, относительно несложные задачи на взаимодействие систем + дальнейшее теоретическое обучение.
• Middle — может самостоятельно решать задачи внутри приложения, а также проектировать небольшие доработки в распределенных системах по образу и подобию (обычно в рамках общепринятого в команде подхода). Самостоятельно спроектировать что-то новое без присмотра не сможет, поэтому требуется наличие сильного инженера, который будет ревьювить решения. Для роста нужны сложные задачи + ментор.
• Senior — может сам проектировать решения в рамках зоны ответственности команды (возможно не одной).
  Для роста нужны новые вызовы.

Уровни сложности собеседования

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

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

Если кандидат кроме happy path ничего не сделал и дальше собеседование выглядит как опрос кандидата с кучей детальных вопросов по частям системы, на которые кандидат отвечает, то это уже уровень Junior.

Как лучше готовиться к собеседованию

Нет ничего лучше совмещения теории и практики. Начнем с теории

Теоретические материалы

• Моя статья про наши System Design Interview
• Моя статья про пробное интервью на C++ Russia 2022
• The System Design Primer —и конкретно теоретическая часть, где излагаются базовые темы, которые стоит знать
• Hacking the Software Engineer Interview by TianPan — ресурс для подготовки к интервью с теорией, которую стоит знать
• Книга “System Design Interview: An Insider’s Guide” и мой краткий обзор предлагаемого в ней фреймворка для прохождения интервью и обзор первой части книги
• Моя статья с 16 рекомендованными книгами по проектированию
• Статья Yandex про System Design Interview с примером задачи про url shortener
• Книга DDIA — отличная книжка, в которой большая часть нужной теории объяснена буквально на пальцах
• Лекции из курса Essential Architecture
  — Лекция про код
  — Лекция про данные
• Крутой курс по распределенным системам (the fault tolerant distributed systems)
  — Лекции
  — Семинары
• Книга Database Internals и ее обзор
  — Part 1 — Storage Engines
  — Part 2 — Distributed Systems
• Репозиторий “Scalable Software Architecture” на Github

Практические материалы

• The System Design Primer — конкретно часть про System Design Exercises, которые можно порешать
• Architectural Katas by Neal Ford — ката с архитектурными задачами, правда без ответов, но примеры задач хорошие
• Hacking the Software Engineer Interview by TianPan — ресурс для подготовки к интервью с примерами, которые стоит порешать

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

Рис.2 “Шаблон задачи”

И помните

Теория без практики мертва, а практика без теории слепа
А. Суворов

Так что используйте в подготовке обе составляющие:)