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