Была ли команда тестировщиков

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

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

Как отвечать

Вопрос о личном опыте, поэтому опирайтесь на свою команду, а не на идеальную схему. Каркас такой:

• устройство: отдельный отдел QA, тестировщик внутри продуктовой команды или тестировщиков не было вовсе. Сколько их было на сколько разработчиков, что они проверяли: ручные сценарии, автотесты на API, нагрузку;
• ваша зона: юнит-тесты на пакете testing в табличном стиле, go test -race в CI, httptest для HTTP-обработчиков, интеграционные тесты с настоящей базой через testcontainers-go, моки через go.uber.org/mock или mockery, линтеры в golangci-lint;
• совместная работа: как QA участвовал в разборе требований, по каким шагам воспроизведения вы чинили баги, кто решал, что задача готова к релизу, были ли отдельные стенды.

Если хочется подкрепить рассказ цифрой, берите ту, что сможете объяснить: сколько багов доходило до прода, сколько длился регресс. Процент вроде «на 30% меньше ошибок» без понимания, как его считали, лучше не называть.

Если тестировщиков не было, скажите прямо и объясните, кто отвечал за качество: разработчики писали тесты, ревью требовало двух одобрений, релиз шёл канареечным выкатом с откатом по метрикам. Такой ответ ничем не хуже. В конце уместно спросить, как устроено тестирование в команде, куда вы собеседуетесь.

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

Отвечают «да, была, они всё проверяли». Звучит так, будто тесты для вас чужая работа, и следующий вопрос будет про покрытие вашего кода.

Жалуются на тестировщиков: медленные, заводили лишние баги. Интервьюер слышит конфликт, а не процесс.

Не могут назвать, какие тесты писали сами и как запускали их в CI. Для Go-разработчика написать табличный тест и прогнать его с -race считается базовым навыком.