Какие инструменты разработки используете: системы контроля версий, баг-трекинг, таск-трекинг

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

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

Как отвечать

Вопрос про ваш опыт, поэтому говорите о своём последнем проекте, а не о возможностях инструментов вообще. Каркас:

• Git и хостинг кода: GitLab, GitHub или Bitbucket, ветка под задачу, merge request с ревью и обязательным зелёным CI. Назовите модель ветвления вашей команды (trunk-based, GitHub Flow или GitFlow) и почему она подходила;
• команды глубже базовых: rebase -i для чистой истории до ревью, cherry-pick для хотфиксов, bisect для поиска коммита с регрессией, reflog для спасения потерянной работы;
• связь с трекером: ключ задачи в имени ветки и в сообщении коммита (PAY-123), тогда тикет сам показывает коммиты и MR;
• трекеры: Jira, YouTrack, Яндекс Трекер, GitLab Issues. Главное не название, а процесс: статусы, кто переводит задачу в тестирование, что считается готовым;
• баг-репорт: шаги воспроизведения, ожидаемый и фактический результат, окружение, версия сборки, стектрейс и кусок лога;
• для Java отдельно: интеграция IntelliJ IDEA с Git и трекером, сборка Maven или Gradle в CI, замечания SonarQube в ревью.

Подкрепите ответ цифрами из своей практики: размер команды, длина спринта, как часто выходили релизы. Если коммерческого опыта ещё нет, честно скажите об этом и покажите свой GitHub: ветки, осмысленные коммиты, Issues и Projects в пет-проекте тоже считаются.

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

Перечисляют названия без процесса. «Работал в Jira» ничего не говорит, интервьюеру важно, как в вашей команде задача проходила от бэклога до релиза.

Знают Git на уровне commit, push и pull. Вопрос про rebase или разрешение конфликта застаёт врасплох, хотя это ежедневная работа.

Ругают инструменты прошлой команды или объявляют один трекер единственно правильным. Интервьюера интересует, насколько легко вы примете чужой процесс, а в новой команде он всё равно будет своим.