System Design Interview: казнить нельзя помиловать

Владимир задаёт тон пародийным проектированием сервиса доставки: кандидат за 45 минут уточняет требования, рисует трёхзвенную схему, добавляет поиск, кэш, Kafka, мониторинг и всё равно не успевает собрать полный ответ. Этот пример выводит вопрос: формат действительно проверяет способность проектировать или воспроизводит набор ожидаемых слов? Филипп видит в заимствовании практики карго-культ. Александр отвечает, что карго-культом становится любой инструмент без понятной цели; оценивать нужно не происхождение секции, а проблему компании и границы применимости решения.

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

В защитной версии System Design оценивает ход мысли. Кандидат должен задать осмысленные вопросы, использовать полученные ответы, выделить зоны ответственности компонентов, провести через них сценарии и обосновать технические решения. Спросить про нагрузку или SLA ради галочки недостаточно: ограничения должны изменить архитектуру. Если знакомая задача решается слишком гладко, интервьюер меняет требование или углубляется в базы, сети и отказоустойчивость. Для очень сильных кандидатов нужен столь же сильный интервьюер; в крупной системе их можно направлять в отдельный пул, но внешние признаки уровня не всегда срабатывают.

Возражение Филиппа касается именно устойчивости этой модели. Кандидаты читают одни и те же книги, учатся рисовать кубики и повторяют решения Twitter или Uber, хотя публичные схемы теряют важные требования и мало похожи на рабочие системы. Даже расчёт средней нагрузки может скрывать пики, а раннее проектирование API — предрешать архитектуру до понимания задачи. Эксперт заметит подмену, но типовой интервьюер может оценить знакомую форму выше незнакомого, но обоснованного решения. В результате подготовка к секции способна не просто слабо предсказывать работу, а распространять плохие архитектурные привычки по индустрии.

Филипп предпочитает разговор о реальном опыте: почему команда выбрала микросервисы или Kafka, какие альтернативы рассматривала и изменились ли скорость, масштаб или надёжность. Он предлагает и более проверяемые упражнения: найти ошибки в чужом дизайне, разобрать чужое интервью, провести интервью самому или назвать тесты для архитектуры. Для SRE естественнее симуляция инцидента, потому что многие из них поддерживают и восстанавливают существующие системы, а не проектируют greenfield. Александр дополняет картину отдельной поведенческой секцией: без неё технически безупречный кандидат может оказаться человеком, который не доводит работу до конца или разрушает взаимодействие в команде.

Контекст меняет и требуемую сложность. Небольшой продукт иногда разумно обслужить одной базой или даже ручным процессом: архитектура на десятки тысяч долларов в месяц не оправдана, если бизнес ещё не доказал спрос. Но маленькой компании трудно оценить первого технического лидера без собственного эксперта. Финальные позиции поэтому остаются разными. Александр сохраняет System Design как практичный дифференциатор senior-уровня и масштабируемый элемент найма, допускающий переделку. Филипп считает текущую форму вредной унификацией и предлагает регулярно менять способы проверки, чтобы содержание не превращалось в репетицию. Общий знаменатель лишь один: секцию нельзя применять автоматически ко всем ролям и задачам.