Я сидел по обе стороны. Я рисовал архитектуру систем на доске, пока интервьюер молча кивал. И я тоже кивал, наблюдая, как кандидат проектирует систему уведомлений на белой доске.
Разрыв между тем, к чему готовятся кандидаты, и тем, что на самом деле оценивают интервьюеры, ошеломляет.
К чему готовятся кандидаты
- Сложные задачи с LeetCode
- Вопросы по obscure алгоритмам
- «Расскажите о случае, когда...»
- Заученные ответы по проектированию систем
Что на самом деле оценивают интервьюеры
Как вы работаете с неопределенностью. Первое, что я делаю, получив задачу по проектированию системы — задаю уточняющие вопросы. «Сколько пользователей? Какие требования к задержке? Какой бюджет?» Кандидаты, которые начинают рисовать блоки, не задав вопросов — красный флаг. Они строят, не понимая требований — и будут делать то же самое в работе.
Понимание компромиссов. Идеальной архитектуры не существует. У каждого выбора есть цена. Когда кандидат говорит «мы должны использовать Kafka для очереди сообщений», я спрашиваю «почему не SQS?» Если он может объяснить компромисс (Kafka: выше пропускная способность, больше операционных затрат, лучшее воспроизведение; SQS: проще, управляемый сервис, достаточно для большинства случаев) — он понимает инженерию. Если он говорит «Kafka — индустриальный стандарт» — он занимается карго-культом.
Мышление в категориях отказов. «Что произойдет, когда этот сервис упадет?» Если ответ «он не упадет» — я понимаю, что кандидат никогда не эксплуатировал систему в продакшене. Падает всё. Вопрос в том, предусмотрели ли вы это в проекте.
Ясность коммуникации. Можете ли вы объяснить свой дизайн не техническому специалисту в комнате? Старшие роли предполагают общение с продакт-менеджерами, дизайнерами и руководителями. Если вы можете объяснить свою систему только другим инженерам — вы достигли своего потолка.
Вопросы, которые я задаю (и что на самом деле проверяю)
«Проведите меня по недавнему проекту, которым вы гордитесь.»
Я проверяю: Можете ли вы рассказать связную историю? Упоминаете ли вы ограничения, а не только технологии? Отдаете ли должное команде или приписываете все заслуги себе? Говорите ли вы, что сделали бы иначе?
«Вы получаете 500 ошибки в продакшене. Проведите меня через ваш процесс отладки.»
Я проверяю: Есть ли у вас системный подход, или вы гадаете? Сначала проверяете логи и метрики, или начинаете менять код? Думаете ли вы о радиусе поражения?
«Спроектируйте систему для [X]. У вас 45 минут.»
Я проверяю: Задаете ли вы сначала вопросы? Начинаете ли с требований или с технологий? Упоминаете ли мониторинг, обработку ошибок и масштабирование — или только счастливый путь?
Что изменилось, когда я начал проводить собеседования
Будучи кандидатом, я думал, что интервьюер ждет «правильного ответа». Став интервьюером, я понял: правильного ответа не существует. Я оцениваю ваш мыслительный процесс.
Кандидат, который проектирует простую систему, признает ее ограничения и объясняет, когда добавил бы сложность, сильнее кандидата, который проектирует сложную систему, но не может ее объяснить.
Мой совет (с обеих сторон)
Кандидатам:
- Задайте 3–5 уточняющих вопросов, прежде чем что-либо проектировать
- Начинайте с простого и добавляйте сложность, когда попросят
- Упоминайте сценарии отказов без подсказки («если этот сервис упадет, произойдет вот что»)
- Объясняйте компромиссы для каждого важного решения
- Будьте честны в том, чего не знаете — «я не работал с Kafka в масштабе, но понимаю преимущества в пропускной способности. Для этого случая я бы начал с SQS и мигрировал, если понадобится воспроизведение»
Интервьюерам:
- Не проверяйте знание конкретных технологий — проверяйте инженерное суждение
- Спрашивайте «что бы вы сделали иначе?» — лучшие инженеры имеют сильные мнения о своей работе
- Давайте кандидатам возможность исправиться — то, как они реагируют на ошибку, говорит о них больше, чем правильный ответ
Лучшие собеседования похожи на рабочие сессии. Худшие — на допросы. Стремитесь к первому.
