Какой состав команды фронтенд разработчиков и как организована работа внутри команды
Что проверяют
Понимаете ли вы, как устроена работа вокруг вас. Чаще это встречный вопрос кандидата, и по ответу многое видно.
Как отвечать
Опишите состав и процессы.
Состав: сколько фронтендеров и какого уровня, есть ли выделенный ведущий, дизайнер, тестировщик, кто отвечает за архитектуру и за общие решения.
Как делится работа. Два подхода: по функциям, когда разработчик ведёт задачу целиком, и по слоям, когда кто-то делает компоненты, а кто-то экраны. Первый быстрее и даёт ответственность за результат, второй приводит к ожиданию друг друга. На практике почти всегда первый.
Общий код. Есть ли дизайн-система или библиотека компонентов, кто её развивает, как принимаются изменения в неё. Без явного владельца такая библиотека либо застывает, либо превращается в свалку.
Взаимодействие с бэкендом, самая болезненная точка. Как согласуется контракт, кто первый: описание API до реализации позволяет фронтенду работать с заглушками параллельно, а «сделаем и покажем» означает простой и переделки.
Работа с дизайном: макеты в общем инструменте, есть ли токены и переменные, кто принимает результат визуально.
Процессы: ревью и требования к нему, договорённости по коду и что проверяет автоматика, тестирование, релизы.
Если это ваш встречный вопрос, самые показательные уточнения: как согласуется контракт API, есть ли дизайн-система и кто её ведёт, сколько времени в среднем висит пул-реквест, и кто решает технические вопросы при разногласиях.
Где спотыкаются
Описывают только свою часть работы.
Не знают, как устроено согласование с бэкендом.
Не спрашивают про дизайн-систему и потом переписывают кнопки в каждом проекте.
Не выясняют, сколько времени занимает ревью.