Дизайн-секция на собеседованиях

В описанном процессе найма разработчик сначала общается с рекрутером, затем проходит технические секции, встречается с командой и при успешном результате получает предложение. Проектирование систем соседствует с алгоритмами и знанием языка, но отвечает на другой вопрос: может ли человек самостоятельно принимать решения за пределами отдельного фрагмента кода? Для Junior и Middle отдельная дизайн-секция в этой схеме обычно не нужна; для Senior и Senior+ она помогает проверить ожидаемую самостоятельность. Это устройство конкретного процесса, представленного в 2021 году, а не универсальное требование ко всем компаниям или гарантия уровня кандидата. Смысл разделения в том, что уверенное программирование само по себе ещё не показывает, как инженер определит границы нового сервиса, договорится о его поведении и выберет способ хранения данных. Эти решения удобнее наблюдать в отдельной задаче, где кандидат может раскрыть рассуждение целиком.

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

После короткой постановки задачи инициативу получает кандидат. Сначала нужно уточнить, что система делает и какие свойства для неё существенны: доступность, согласованность данных, пропускная способность, масштабируемость или возможность восстановить историю действий. Вопросы выбираются по смыслу задачи. Число пользователей, частота запросов и объём хранения нужны для последующих решений; механически перечислить их недостаточно. Полезно сразу сформулировать предположения о нагрузке и зафиксировать ответы рядом с условием. Следующий шаг — очертить границы системы, её клиентов, поддерживаемые сценарии и публичный API. На этом уровне внутреннее устройство ещё не определено: сначала согласуется, что система обещает окружающему миру. Автор связывает этот взгляд с контекстной диаграммой C4. Общая доска помогает держать договорённости перед глазами и возвращаться к ним при проверке решения. Перед началом интервьюер также знакомит кандидата с инструментом рисования, чтобы технические действия с доской не мешали обсуждению самой системы.

Внутреннюю схему удобно строить по движению данных: откуда приходит запрос, какие действия выполняются, где данные сохраняются и что передаётся дальше. Компоненты появляются потому, что нужны для сценария. Сначала разбирается обычное успешное выполнение, затем — исключения и отказ отдельных частей. Здесь же проверяются ограничения: например, допустима ли потеря пользовательской задачи и за какое время она должна быть выполнена. Концептуальная схема фиксирует классы компонентов и хранилищ, модели обмена, данные в памяти и постоянном хранении. Затем можно выбирать конкретные технологии и рассчитывать необходимые мощности. Однако возможность масштабирования проверяется уже при построении концепции: у наиболее нагруженных частей должен быть понятный способ горизонтального роста. Если нагрузку вспомнить только в конце, красивый рисунок может потребовать пересмотра. Важно показать, какие исходные числа влияют на устройство системы, и объяснить, почему выбранные компоненты подходят именно под эти условия, а не просто знакомы по предыдущей работе.

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

Автор разбирает именно такой неоднородный профиль. Кандидат уверенно уточняет требования, определяет границы и API, показывает основные и исключительные сценарии, строит концептуальную схему и модели данных. Но конкретные технологии выбирает преимущественно из знакомого набора, не объясняя их пригодность. Параметры нагрузки появляются после подсказки и почти не меняют решение; дополнительные вопросы обнаруживают ограниченный технический кругозор. В этом примере автор ставит Middle именно за проектирование распределённых систем и отдельно перечисляет сильные стороны и пробелы для кандидата и будущего руководителя. Из такого разбора получается предметная программа подготовки: тренировать недостающие шаги решения, расширять понимание технологий и учиться связывать ограничения с архитектурой. В качестве источников доклад предлагает книги о проектировании, System Design Primer, курс Мартина Клеппмана по распределённым системам, Essential Architecture и профильные конференции. Они помогают разбирать причины решений; применить знания всё равно предстоит в связном рассуждении над конкретной задачей.