Как поступали задачи и в каком виде

Что проверяют

Насколько зрелым был процесс на прошлом месте и как вы действуете, когда задача сформулирована плохо. По сути это проверка самостоятельности: ждёте ли вы идеального ТЗ или сами добываете недостающее. Следом обычно спрашивают: «А что делали, если требования были непонятны?»

Как отвечать

Вопрос про ваш реальный опыт, поэтому нужны свои детали: трекер, длина спринта, кто ставил задачи, какая доля приходилась на незапланированное. Удобный каркас:

• источник: продакт или аналитик в Jira или YouTrack, баги от поддержки и из Sentry, технический долг от самой команды;
• формат: пользовательская история с критериями приёмки, ТЗ от аналитика со спецификацией API в OpenAPI, иногда просто сообщение в чате;
• уточнение: что вы делали с размытой задачей. Например, задавали вопросы в тикете, фиксировали договорённости письменно, делали короткий прототип;
• оценка и приоритет: кто оценивал, где обсуждали, кто решал, что важнее;
• путь до прода: ветка, pull request, ревью, CI с pytest и линтерами, выкладка, кто проверял результат.

Пример хорошего ответа: «Задачи ставил продакт в Jira, у бэкенд-задач была схема эндпоинта в OpenAPI. Если не хватало деталей, я уточнял до начала работы и записывал ответ в тикет. Срочные баги шли из Sentry вне спринта».

Если процесса почти не было, скажите честно: задачи приходили в мессенджере. Потом покажите, что делали сами: переносили их в трекер, просили критерии приёмки, сверяли результат перед закрытием. Это ценнее выдуманного Scrum.

Где спотыкаются

Отвечают одним словом: «через Jira». Спрашивают про процесс, а не про инструмент.

Ругают бывшего работодателя за хаос. Интервьюер слышит, как вы будете говорить про новую команду.

Рассказывают идеальный процесс из учебника или добавляют проценты вроде «производительность выросла на 20%». Пара уточняющих вопросов про длину спринта и ретро это вскрывает.