Как устроен процесс работы с аналитиком и тимлидом
Что проверяют
Умеете ли вы работать с требованиями до того, как сели писать код, и понимаете ли, за что отвечает каждая роль. Интервьюер хочет услышать, что вы не ждёте идеального ТЗ молча, но и не решаете продуктовые вопросы в одиночку. Частое уточнение: что вы делаете, если требования поменялись посреди задачи.
Как отвечать
Разведите роли и опишите свой цикл на реальной задаче:
- аналитик: пишет требования и user story, описывает бизнес-правила и валидации, часто согласует с бэкендом контракт API в OpenAPI. Он отвечает на вопрос «что должно происходить»;
- тимлид: отвечает за декомпозицию, оценки, технические решения и ревью, снимает блокеры и разруливает конфликты приоритетов. К нему идут с вопросом «как делаем» и с рисками по срокам.
Свой цикл можно описать так. Перед стартом вы читаете требования и макеты в Figma и задаёте аналитику вопросы, которые обычно упускают: пустые состояния, ошибки и коды ответа, пагинация, права доступа, длинные тексты, мобильная ширина. Пока бэкенд не готов, работаете на моках по контракту, например через MSW. Готовую задачу показываете аналитику на стенде до передачи в QA. Если дизайнер или менеджер в чате просит поменять поведение, изменение проходит через аналитика и фиксируется в задаче, иначе через неделю никто не вспомнит, почему кнопка работает именно так.
Приведите свой пример, где вопрос к аналитику до разработки сэкономил переделку. Если отдельного аналитика не было, скажите честно и расскажите, как требования уточняли с продактом или бэкендом напрямую.
Где спотыкаются
Описывают себя исполнителем: «аналитик пишет ТЗ, я делаю». Интервьюеру нужен человек, который находит дыры в требованиях заранее.
Жалуются на аналитиков и тимлидов прошлой команды. Даже если было тяжело, говорите о процессе, а не о людях.
Подкрепляют рассказ выдуманными результатами вроде «сдали на два месяца раньше». Лучше скромная, но проверяемая деталь: сколько вопросов закрыли на груминге и насколько реже задачи стали возвращаться из QA.