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

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

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

Как отвечать

Опишите путь задачи от идеи до прода на своём примере:

• источник: продакт или аналитик ведёт бэклог в Jira, YouTrack или GitLab Issues, баги приходят от QA и из мониторинга (Sentry, алерты);
• подготовка: груминг, где задачу уточняют и оценивают в story points или часах, критерии готовности к работе (definition of ready);
• распределение: планирование спринта с закреплением за исполнителем или канбан, где разработчик сам берёт верхнюю задачу из колонки;
• выполнение: ветка, merge request, ревью, CI с pytest, ruff и mypy, выкладка на стенд и проверка QA;
• обратная связь: демо, ретро, порядок работы со срочными задачами посреди спринта.

Добавьте свою роль: брали ли задачи сами, участвовали ли в оценке, разбивали ли крупную фичу на подзадачи. Для Python-команды уместно рассказать, как планировали техдолг и миграции Alembic или Django, чтобы они не копились.

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

Если опыта в команде не было, расскажите про стажировку, open source или учебный проект с issues и ревью, и прямо скажите, что с полным циклом ещё не работали.

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

Отвечают одним словом «Scrum». Интервьюеру нужен реальный путь задачи, а не название методологии.

Ругают бывшую команду и менеджера. Это читается как будущая проблема, говорите о процессе, а не о людях.

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