Какой состав команды был на самом интересном проекте
Что проверяют
В команде какого масштаба вы работали и как в ней была устроена работа фронтенда: с кем вы договаривались, кто принимал решения, где проходила ваша граница ответственности. Следом обычно спрашивают, как вы согласовывали API с бэкендом или что было самым сложным во взаимодействии.
Как отвечать
Отвечайте на своём проекте и со своими цифрами. Удобный порядок:
- почему проект интересный: одна фраза. Сложный интерфейс, большая нагрузка, запуск с нуля, миграция со старого стека;
- состав: сколько фронтендеров, бэкендеров, дизайнеров, тестировщиков, был ли аналитик или продакт, кто отвечал за DevOps. Например: «три фронтенда, пять бэкендов, дизайнер, два QA и продакт»;
- ваша роль: какую часть интерфейса вели, были ли ревьюером, принимали ли архитектурные решения;
- как работали с соседями: контракт API через OpenAPI и моки на MSW, чтобы не ждать бэкенд; передача макетов в Figma, дизайн-система и Storybook; кто и как проверял релиз;
- результат: что изменилось благодаря вашей работе. Скорость загрузки по Core Web Vitals, число экранов, меньше багов после релиза. Числа только настоящие.
Если вы были единственным фронтендером, это не минус: расскажите, какие решения принимали сами и как держали качество без ревью от коллеги. Если коммерческого опыта нет, возьмите учебный командный проект или open source и честно назовите его так, придумывать команду не нужно.
Где спотыкаются
Перечисляют роли и на этом заканчивают. Состав сам по себе интервьюеру неинтересен, ему важно, как вы с этими людьми работали.
Говорят только «мы»: «мы сделали, мы решили». После ответа непонятно, что сделали лично вы, и интервьюер начинает это вытягивать.
Критикуют бывших коллег: «бэкенд всё время срывал сроки». Даже если так и было, лучше показать, что вы сделали, чтобы это не блокировало вашу работу, например подняли моки по контракту.