Как выглядела ваша рутина на последнем месте работы и как получали задачи

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

Насколько вы встроены в процесс разработки и быстро ли войдёте в процесс новой команды. По ответу видно, получали вы готовые тикеты или сами уточняли требования, и как задача доходила до прода. Следом часто спрашивают, что в этом процессе мешало и что бы вы поменяли.

Как отвечать

Опишите обычную неделю по порядку, на своих реальных примерах. Каркас:

• откуда приходят задачи: бэклог в Jira или YouTrack, планирование спринта, оценка в стори поинтах или часах; срочные баги из поддержки или алертов идут мимо спринта;
• как уточняются требования: с кем вы говорите, с аналитиком, продактом или тимлидом, и что делаете с неясным тикетом;
• путь задачи: ветка от main, код и тесты на pytest, проверки в CI (линтер ruff, типы через mypy), merge request, код-ревью, тестовый стенд, релиз;
• ритуалы: дейли, груминг, ретро, и что из этого реально работало;
• ваша доля: сколько времени уходило на фичи, сколько на баги и дежурства, ревьюили ли вы чужой код.

Цифры берите свои и проверяемые: длина спринта, размер команды, сколько MR в неделю, сколько обычно ждали ревью. Выдуманное «удовлетворённость клиентов выросла на 20%» интервьюер распознаёт сразу, и дальше вам верят меньше.

Если процесса почти не было (стартап, фриланс, вы единственный разработчик), так и скажите и опишите, как организовывали работу сами: список задач, приоритеты с заказчиком, свой CI. Это честный и вполне сильный ответ.

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

Пересказывают Scrum Guide вместо своей работы. Фраза «мы работали по Agile» ничего не сообщает, интересно, как именно задача попадала к вам.

Жалуются на прошлую команду и менеджера. Недостатки процесса назвать можно, но вместе с тем, что вы сами пытались с ними сделать.

Отвечают так, будто задачи приходили уже разжёванными. Это звучит как отсутствие инициативы, поэтому покажите хотя бы один случай, когда вы уточнили или переформулировали требование до начала работы.