Вы руководитель команды фронтенд

Что проверяют

Вопрос оформлен как кейс: вас ставят в роль и смотрят, как вы думаете о команде, а не о коде. Интервьюеру важно понять, есть ли реальный опыт руководства и где у вас граница между лидом и самым сильным разработчиком. Следом дают ситуацию: сорванный срок, конфликт двух разработчиков, человек, который не справляется.

Как отвечать

Стройте ответ вокруг трёх зон ответственности и в каждой приводите свой пример:

• качество кода: общие правила вместо вкусовых споров. Строгий TypeScript, ESLint и Prettier в CI, ревью с понятными критериями, Definition of Done с тестами и проверкой в нужных браузерах. Архитектурные решения коротко фиксируются, например в ADR;
• поставка: декомпозиция, честные оценки, техдолг как часть плана, а не «когда будет время». Фронтенд часто упирается в бэкенд и дизайн, поэтому договорённость о контрактах API и дизайн-система в Storybook экономят недели;
• люди: встречи один на один, план роста для каждого, онбординг с первым небольшим тикетом в прод за первую неделю, распределение экспертизы, чтобы не было незаменимых.

Про результат говорите своими цифрами и тем, как они посчитаны: время от задачи до прода, число откатов после релиза, Core Web Vitals по данным реальных пользователей, срок онбординга. Одна измеренная цифра убедительнее трёх красивых процентов.

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

Где спотыкаются

Отвечают набором ритуалов: стендапы, ревью, ретро. Процессы без объяснения, какую проблему они решали, звучат заученно.

Обещают в первый месяц переписать всё на новый фреймворк или замыкают всё ревью на себя. Первое пугает бизнес, второе делает лида узким местом.

Приводят результат вроде «ошибок стало меньше на 30%», но не могут сказать, откуда цифра. Интервьюер обязательно спросит, как считали.