Используешь ли багтрекинговые системы

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

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

Как отвечать

Назовите инструменты, с которыми работали: Jira, YouTrack, GitLab Issues, GitHub Issues, Linear. Интереснее не список, а процесс вокруг трекера. Опишите его на своём примере:

• связь с кодом: ветка и коммиты содержат ключ задачи, например PAY-412, и трекер сам подтягивает merge request. В GitHub и GitLab фраза Fixes #123 в описании закрывает задачу при слиянии;
• поток ошибок: паники и ошибки сервиса собирает Sentry через sentry-go или похожий инструмент. Оттуда задача создаётся со стеком, версией сборки и trace ID;
• хороший репорт: шаги воспроизведения, ожидаемое и фактическое поведение, окружение, версия или коммит, логи с идентификатором запроса. Для Go ценны полный стек паники и вывод go test -race, если подозревается гонка;
• исправление: сначала тест, который воспроизводит баг и падает, потом фикс. Тест остаётся в репозитории и не даёт ошибке вернуться;
• приоритет и серьёзность: это разные поля. Опечатка на главной бывает срочной, а падение редкого отчёта может подождать.

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

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

Отвечают одним словом «Jira». Интервьюер хочет услышать, как вы с ней работали, а не название продукта.

Приводят цифры вроде «сократили время исправления на 30%», не зная, как это измеряли. Одна такая фраза подрывает доверие ко всему ответу.

Закрывают баг без регрессионного теста и без ссылки на коммит. Через месяц ошибка возвращается, и никто не может найти, что тогда меняли.