Какой размер команды и сколько в ней программистов и тестировщиков

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

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

Как отвечать

Опишите команду тремя слоями: люди, зона ответственности, процесс качества.

• люди: сколько Go-разработчиков, есть ли тимлид, QA, SRE или DevOps, продакт, аналитик. Например: «пять разработчиков на Go, один QA на две команды, общий SRE на отдел»;
• зона ответственности: сколько сервисов у команды, какая нагрузка, какие хранилища и очереди: PostgreSQL, Kafka, Redis;
• качество: что делали разработчики. Для Go-команды норма: табличные тесты на стандартном testing, httptest для хендлеров, интеграционные тесты на реальной базе через testcontainers-go, прогон с флагом -race в CI. QA при этом держит сквозные сценарии и регрессию;
• ваша роль: какие сервисы были на вас, участвовали ли в дежурствах, ревью, найме.

Пропорцию программистов и тестировщиков не нужно оправдывать, её нужно знать и уметь объяснить. Если тестировщиков не было совсем, расскажите, чем это компенсировали: покрытием тестами, канареечными выкладками, метриками и алертами.

Цифры берите свои. Если командного опыта мало (стажировка, один проект), так и скажите, опишите состав той команды и то, что делали лично вы. В конце уместно задать встречный вопрос: как устроена команда, в которую вас нанимают.

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

Отвечают «обычно команды бывают от пяти до десяти человек» вместо описания своей. Вопрос поведенческий, общие рассуждения здесь не засчитываются.

Приписывают себе заслуги всей команды. «Мы сократили задержку вдвое» сразу вызывает уточнение, что именно сделали вы, и расплывчатый ответ на него хуже скромной, но точной формулировки.

Перекладывают всё качество на тестировщиков. Для Go-разработчика хороший сигнал другой: тесты вы писали сами, а QA был партнёром, который смотрит на продукт глазами пользователя.