Как происходит работа с задачами и тикетами

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

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

Как отвечать

Опишите жизненный цикл тикета в вашей команде и свои действия на каждом шаге:

• трекер и статусы: Jira, YouTrack или GitLab Issues. Типичный путь: To Do, In Progress, Code Review, Testing, Done. Если у вас он другой, назовите свой;
• перед стартом: читаете описание и критерии приёмки, уточняете непонятное комментарием в тикете, при необходимости режете задачу на подзадачи и ставите оценку;
• связь с кодом: ключ задачи в названии ветки и в сообщении коммита, например PROJ-123. Трекер сам подтягивает ветку и MR, а через год по git log видно, зачем меняли строку;
• по ходу работы: статус соответствует реальности, блокеры озвучиваются на стендапе и записываются в тикет, туда же попадают решения из созвонов;
• проверки: MR проходит CI с pytest, ruff, mypy и ревью коллеги;
• закрытие: по Definition of Done задача закрыта, когда код выложен и проверен, а не когда влит MR.

Отдельно скажите, что делаете с запросами из чата: заводите тикет сами или просите автора. Работа, которой нет в трекере, не попадает в планирование и делает оценки спринта бессмысленными.

Опирайтесь на свою реальную практику и свои примеры. Если вы работали без трекера, в маленькой команде или на фрилансе, так и скажите и объясните, как вели учёт: задачи в GitLab, доска в Notion, письменные договорённости с заказчиком.

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

Переносят тикет в Done сразу после слияния. Если на стенде всплывёт баг, задача формально закрыта, и о ней никто не вспомнит.

Отвечают выдуманным STAR с процентами вроде «сократили время на 20%». Интервьюер спросит, как это измеряли, и ответ рассыплется.

Называют только инструмент: «работали в Jira». Непонятно, что именно вы делали с тикетом, от уточнения требований до закрытия.