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