Что такое система git и насколько хорошо вы с ней знакомы
Что проверяют
Вопрос отсеивающий: за минуту выясняют, работали ли вы в команде и понимаете ли, что происходит с историей. Слабый ответ это перечень команд, сильный это рассказ про рабочий процесс и про то, как вы чините сломанное.
Как отвечать
Коротко про суть: распределённая система контроля версий, у каждого разработчика полная копия истории. Коммит хранит снимок дерева и ссылку на родителя, ветка это подвижный указатель на коммит, поэтому ветвление дёшево.
Дальше про свой процесс, конкретно: ветка на задачу от основной, небольшие коммиты осмысленными сообщениями, обновление ветки от основной перед ревью, слияние после проверки. Скажите, какой порядок принят у вас и почему именно такой.
Отдельно покажите инструменты разбора, они и отличают опытного: git log с фильтрами, git blame, git bisect для поиска коммита, сломавшего сборку, git reflog для возврата после неудачного сброса, git revert для отката уже опубликованного коммита.
Для Go добавьте своё: go.mod и go.sum конфликтуют почти при каждом слиянии, и правят их не руками, а повторным go mod tidy; сгенерированный код и собранные бинарники в репозиторий не кладут; версии модуля задаются тегами, а мажорная версия выше первой требует суффикса в пути импорта.
Где спотыкаются
Делают git add . и уносят в коммит чужие правки, временные файлы и локальный конфиг. Добавлять стоит перечислением путей, а перед коммитом смотреть собственный дифф.
Переписывают опубликованную историю. Перебазирование или правка коммита в общей ветке ломают работу всем, кто на ней стоит. Если без этого никак, то git push --force-with-lease, а не обычный форс.
Не умеют откатывать. На вопрос о возврате состояния отвечают только про reset --hard, теряют работу и не знают, что для опубликованного нужен revert, а потерянное почти всегда лежит в reflog.