Как на самом деле готовиться к System Design интервью

Секция появилась в 2020 году: в компанию пришёл Игорь Маслов заниматься платформенными вещами, ему нужно было набирать много людей, и он предложил унифицировать найм. Сначала было около пяти задач и десяток интервьюеров, которых Игорь отобрал сам, — но не было ни критериев, ни общего понимания, как трактовать результат: каждому просто верили, что он хорошо проектирует и распознает это в других. Когда Игорь ушёл на другие задачи, секция досталась Александру; в один из годов большого найма он провёл двести интервью без одного — System Design, менеджмент, траблшутинг. Дальше появились семишаговый процесс, матрица оценки, которую потом рефайнили, пул задач и материалы для кандидатов с предложением вернуться через полгода. В 2024-м он передал секцию коллеге. Рядом живёт архитектурная секция для staff+: там разбирают не выдуманную задачу, а реальные кейсы человека и его зону ответственности.

Книга про System Design много лет висела камнем на душе: оглавление и куча глав в Google Doc, которые не двигались. В конце прошлого года компания начала делать внутренний аналог инструментов вроде Manus, Александр глубоко разобрался, как они работают, и собрал на нём сайт исследования про AI в разработке — трек, за который он с прошлой недели отвечает официально. Из интереса он загрузил туда же книгу, получил первую версию сайта и дальше по одной переносил свои старые статьи в главы, добавляя визуализации; занятие затянуло на январские каникулы. Григорий хвалит интерактивные примеры вроде circuit breaker, который можно покрутить прямо на странице. Книгу Александр, по его признанию, не дописал бы: мотивация появилась только когда сайтом начали пользоваться. Фидбэк после анонса он почти весь починил за вечер и утро, а сложное отложил — маршрут обучения и спор про лонгриды, которые часть читателей просит вернуть.

Задача секции — увидеть, как человек мыслит. Многие проваливаются уже на первом шаге: кандидат читает условие, говорит «всё понятно» и проектирует систему, которую придумал сам, не уточнив сценарии, нагрузку, режимы работы и точки интеграции. Интервьюер тогда докидывает недостающее по ходу — «а пользователей вот столько», «а основной сценарий был такой», — и через двадцать минут выясняется, что нарисованная система решает другую задачу. Григорий добавляет свой пример: в его задаче по сети гоняется всего десять килобайт, но кандидат, который не посчитал нагрузку, успевает нарисовать космолёт. Противоположная крайность не лучше: требования можно собирать бесконечно. Александр вспоминает траблшутинг-интервью, где кандидат сорок минут собирал логи, но не сделал ни одного действия, чтобы починить инцидент; в фидбэке он написал, что летописец инцидента вышел бы отличный, а инженер вряд ли. Требования и атрибуты качества — пререквизит, но из паралича анализа надо выйти и начать проектировать.

Сам он предлагает начинать с чёрного ящика: что система обещает наружу и кому. Сегодня эта фиксация обычно выглядит как API — контракт, за границами которого стоят конкретные потребители. Ошибиться можно в обе стороны: не зафиксировать нужные контракты или, наоборот, притащить всё подряд — аутентификацию, квоты, админку, выгрузку в дата-платформу, — после чего проектировать придётся весь день, вместо того чтобы сузить скоуп до обсуждённых сценариев. Те, кто начинает с сущностей и моделей данных, больше чем в девяти случаях из десяти приземляются в выбор базы раньше, чем понимают, какой сценарий закрывают. Дальше нужны не красивые диаграммы, на них не хватит часа, а черновой набросок: пять-шесть кубиков, через которые проходят запросы и события, и прогон сценариев по ним. Тут же всплывают атрибуты качества и SLA. Александр вспоминает, как почти двадцать лет назад спроектировал соцсеть, которая отлично работала на сотне человек, а на десяти тысячах сложилась под многоэтажными селектами.

Отдельный сорт ответа — «здесь поставим кэш, тут воткнём Kafka»: все модные слова на месте, и если бы интервьюер не шарил, он назвал бы это хорошим проектированием. Александр вспоминает кандидата, который быстро и красиво разложил систему за полчаса, но забыл основное требование и отказался переделывать, пытаясь закрыть дыру хотфиксами; когда его начали спрашивать вглубь, про распределённые системы и фундамент из второй части сайта, там оказалась пустота — при том что оферы в других компаниях у человека уже были. Свой промах он рассказывает не менее откровенно: с некоторым высокомерием дал задачу из домена кандидата, тот отвечал блестяще, оценка вышла завышенной, а коллеги потом пришли с вопросами — задача оказалась полуслитой. С тех пор правило простое: если всё идёт слишком гладко, задачу надо уводить от дефолтной, подкрутив требования или добавив сценарии. Бывает и наоборот: руководитель с трейдинговым опытом решил одну из задач иначе, чем в эталоне, но оптимальнее под условие.

На интервью почти всегда greenfield и свобода в выборе технологий, в работе — brownfield, ограниченный стек и интеграции: проектируешь не лучшую систему, а ту, что дешевле встроится в ландшафт, и смотришь, кто в команде будет это поддерживать. Пример — попытка сделать новую авторизацию на relationship-based access control по гугловскому подходу, где граф прав лежит триплетами: гибкую модель не порезать на шарды, стенд на распределённых базах показал, что красивые цифры вендоров сделаны под другой профиль нагрузки, а на профиле команды база нагружается гораздо сильнее, железо стоит конских денег, а система выходит сверхсложной. Оставили API и модель данных, но нарезали граф под конкретные типы запросов. Следующий формат интервью Александр представляет как brownfield-проект с агентом: в его демо не было ни тенантности, ни API, и добавление тенантной модели заняло примерно час. Сначала это надо обкатать на своих сотрудниках. Агент пишет код и иногда проектирует, но без базы его не направить и не проверить: джуниору легко передать вместе с задачей и ответственность.