Расскажите о вашем опыте работы с Git
Что проверяют
Для тестировщика вопрос про Git это вопрос о том, насколько вы встроены в процесс разработки. Автоматизатор хранит тесты в репозитории и живёт по тем же правилам, что и разработчики. Ручной тестировщик всё равно обязан понимать, что попало в сборку, которую он проверяет, и откуда взялась регрессия. По ответу видно, где вы находитесь между этими полюсами.
Как отвечать
Разделите два слоя.
Свой код: где лежат автотесты (в репозитории продукта или отдельно и почему так), ветка на задачу, ревью тестов такое же, как ревью кода. Скажите, как тесты попадают в сборку и что происходит, когда проверка на ветке падает.
Работа с чужими изменениями: что смотрите перед проверкой задачи. git log по ветке, чтобы понять состав сборки, git diff между метками или коммитами, чтобы увидеть область изменений и точнее выбрать регрессионные проверки, метки релизов, чтобы знать, что именно стоит на стенде. Отдельный сильный пункт: поиск коммита, после которого появился дефект. git bisect находит его за несколько шагов вместо ручного перебора, и знание про эту команду выделяет кандидата.
Упомяните практики, которые касаются именно тестов: тестовые данные и артефакты прогонов в репозитории не хранят, адреса стендов и учётные записи выносят в переменные окружения, отчёты о прогонах не коммитят вовсе, иначе конфликты в них придётся разбирать руками.
Где спотыкаются
Первое: говорят, что Git это дело разработчиков. Даже без автоматизации тестировщик обязан сказать, какая версия на стенде и какие правки в неё вошли. Отказ от этой части выглядит как узкий кругозор.
Второе: путают ветку и окружение. Кандидат уверен, что проверяет свою ветку, хотя на стенд собирается что-то другое. Привычка сверять сборку с коммитом или меткой снимает половину споров с разработчиками о невоспроизводимых дефектах.
Третье: автотесты коммитят одной кучей в конце. Такой коммит невозможно нормально отревьюить и нельзя частично откатить, а падение тестов потом не связать с конкретным изменением.