На Lead-позиции обычно проверяют не только знание технологий, но и способность удерживать систему, людей и последствия решений.
От кандидата ожидают, что он умеет принимать решения в условиях ограничений, отвечать за результат команды, управлять техническими рисками и объяснять свои решения как инженерам, так и бизнесу.
Contents
1. Архитектура и технические решения
Типовые вопросы:
- Как вы выбираете архитектуру?
- Когда монолит лучше микросервисов?
- Как понять, что архитектура не масштабируется?
- Как вы принимаете спорное техническое решение?
- Как вы документируете архитектурные решения?
- Что такое technical debt и как его контролировать?
- Как вы решаете, рефакторить сейчас или позже?
- Как вы оцениваете риски технического решения?
В ответах важно показывать не приверженность конкретному архитектурному стилю, а умение учитывать требования, нагрузку, зрелость команды, стоимость эксплуатации, сроки и обратимость решения.
2. Качество кода и code review
Типовые вопросы:
- Как вы проводите code review?
- Что для вас означает плохой код?
- Когда можно отказаться от идеального решения ради дедлайна?
- Как вы вводите стандарты разработки в команде?
- Что делать, если разработчик регулярно пишет слабый код?
- Как вы снижаете количество дефектов?
- Какие метрики качества кода вы используете?
Lead должен рассматривать code review не только как поиск ошибок, но и как инструмент распространения знаний, согласования инженерных подходов и управления риском изменений.
Качество нельзя сводить к покрытию тестами или результатам статического анализа. Важны также понятность, связанность компонентов, сложность изменений, частота регрессий и поведение системы в production.
3. Delivery и ответственность за результат
Типовые вопросы:
- Как вы оцениваете сроки?
- Что делать, если команда не успевает?
- Как вы сообщаете заказчику о рисках?
- Как вы работаете с нечёткими требованиями?
- Что делать, если бизнес требует быстрое, но технически опасное решение?
- Как вы приоритизируете задачи?
- Как понять, что задача готова к разработке?
Сильный ответ должен показывать, как кандидат выявляет неизвестные факторы, зависимости и риски, сокращает объём задачи, согласовывает критерии готовности и сообщает об отклонениях до срыва срока.
Lead отвечает не за первоначальное обещание, а за управляемое движение к результату и своевременную корректировку плана.
4. Люди и лидерство
Типовые вопросы:
- Как вы менторите разработчиков?
- Как вы решаете конфликт в команде?
- Что делать, если senior-разработчик не согласен с вашим решением?
- Как вы даёте негативную обратную связь?
- Как вы мотивируете команду?
- Как вы делегируете?
- Как понять, что человек растёт?
- Что делать с токсичным, но технически сильным разработчиком?
В этих вопросах проверяют способность Lead-а различать техническое разногласие, личный конфликт, недостаток контекста и проблему поведения.
Хороший ответ содержит конкретный способ действий: сбор фактов, разговор с участниками, фиксацию ожиданий, критерии изменения поведения и последующую проверку результата.
5. Коммуникация с заказчиком и менеджментом
Типовые вопросы:
- Как вы объясняете технические риски бизнесу?
- Как вы разрешаете разногласия с product owner?
- Как вы работаете, если требования постоянно меняются?
- Как вы защищаете команду от хаотичных запросов?
- Как вы переводите бизнес-требования в техническое решение?
Технический риск следует объяснять через влияние на бизнес:
- вероятность и последствия сбоя;
- влияние на сроки и стоимость;
- возможные варианты решения;
- компромиссы каждого варианта;
- рекомендуемое действие.
Задача Lead-а — не оградить команду от любой неопределённости, а преобразовать неопределённость в приоритеты, решения и понятные ограничения.
6. System Design
Типовые задания и вопросы:
- Спроектируйте сервис уведомлений.
- Спроектируйте систему загрузки файлов.
- Спроектируйте очередь обработки задач.
- Как обеспечить идемпотентность?
- Как реализовать retry без дублирования?
- Как масштабировать API?
- Как работать с распределёнными транзакциями?
- Где использовать Kafka, а где обычную очередь сообщений?
- Как проектировать систему с eventual consistency?
На этом этапе оценивают не количество названных технологий, а последовательность рассуждений:
- Уточнение функциональных и нефункциональных требований.
- Оценка нагрузки и объёма данных.
- Выделение компонентов и контрактов.
- Выбор модели данных и способов взаимодействия.
- Анализ отказов, повторов и конкурентных запросов.
- Масштабирование и наблюдаемость.
- Обсуждение компромиссов и альтернатив.
7. Production и надёжность
Типовые вопросы:
- Что делать, если сервис упал?
- Как вы ищете причину инцидента?
- Какие логи и метрики нужны?
- Что такое SLA, SLO и SLI?
- Как вы строите стратегию отката?
- Как избежать breaking changes?
- Как проводить релиз безопасно?
Lead должен разделять восстановление сервиса и поиск первопричины. Во время инцидента приоритетом является уменьшение влияния на пользователей: rollback, отключение проблемной функции, переключение трафика или деградация сервиса.
После стабилизации проводится анализ причин, фиксируются корректирующие действия и проверяется, что аналогичная проблема будет обнаружена раньше или не повторится.
8. Тестирование
Типовые вопросы:
- Какие виды тестов нужны?
- Где проходит граница между unit-, integration- и end-to-end-тестами?
- Как понять, что тестов достаточно?
- Что делать с flaky tests?
- Как тестировать микросервисы?
- Как вы строите стратегию тестирования?
Стратегия тестирования должна следовать рискам системы. Критичные бизнес-правила проверяются быстрыми и устойчивыми тестами, интеграционные контракты — интеграционными или контрактными тестами, а ключевые пользовательские сценарии — ограниченным набором end-to-end-тестов.
Количество тестов само по себе не является целью. Важны скорость обратной связи, устойчивость набора тестов и способность обнаруживать значимые регрессии.
9. Поведенческие вопросы
Типовые вопросы:
- Расскажите о сложном техническом решении.
- Расскажите о конфликте.
- Расскажите о провале.
- Расскажите, когда вы ошиблись как лидер.
- Расскажите, как вы повлияли на команду.
- Расскажите, как вы улучшили процесс.
- Расскажите, когда вам пришлось взять ответственность за чужую зону.
Для каждого вопроса следует заранее подготовить реальный пример. Ответ без конкретной ситуации, собственных действий и измеримого результата воспринимается как теоретический.
Структура сильного ответа
На Lead-вопросы удобно отвечать по схеме:
Ситуация → проблема → анализ → решение → результат → вывод.
Ситуация
Кратко описать систему, команду и исходные ограничения.
Проблема
Назвать конкретную угрозу для результата: задержка, сбой, конфликт, рост нагрузки, потеря качества или неясность требований.
Анализ
Объяснить, какие данные были собраны, какие причины и варианты рассматривались, какие компромиссы были обнаружены.
Решение
Показать собственную роль: что именно кандидат предложил, согласовал, делегировал или реализовал.
Результат
Назвать наблюдаемый эффект: изменение latency, количества ошибок, срока доставки, стоимости эксплуатации или поведения команды.
Вывод
Объяснить, что было изучено и что в следующий раз будет сделано иначе.
Пример ответа
Слабый ответ:
Я знаю Kafka и использовал её для асинхронной обработки.
Сильный ответ:
У нас была проблема с синхронной обработкой: тяжёлые операции увеличивали latency API и приводили к тайм-аутам. Мы вынесли обработку в очередь, добавили idempotency key, ограниченную retry policy, dead letter queue и мониторинг задержки сообщений. В результате снизили latency пользовательских запросов и сократили количество production failures. После запуска мы также добавили алерт на рост очереди, потому что первоначально обнаруживали перегрузку слишком поздно.
Второй ответ демонстрирует не только знание технологии, но и понимание проблемы, критериев выбора, эксплуатационных последствий и результата принятого решения.
