Был ли отдельный отдел или вы отвечали за продакшен
Что проверяют
Где в прошлой команде проходила граница ответственности QA: заканчивалась ли она на тестовом стенде или вы участвовали в релизе и следили за продом. По ответу понимают, насколько вы самостоятельны. Следом почти всегда просят рассказать, что вы делали, когда баг всё-таки доехал до пользователей.
Как отвечать
Сначала коротко опишите устройство команды, потом свою роль. Каркас на своём опыте:
- кто выкатывал: отдельные DevOps или SRE, дежурный разработчик или сама команда по кнопке в CI;
- ваша зона в релизе: регресс на стейдже, решение «можно выпускать» (release sign-off), чек-лист релиза, смоук на проде сразу после выкладки;
- доступ к проду: был ли он и какой (чтение логов, тестовые аккаунты в бою), по каким правилам вы проверяли, не трогая данные реальных клиентов;
- мониторинг: где смотрели ошибки после релиза (Sentry, Grafana, Kibana или другой стек), кто получал алерты;
- инциденты: как проходил хотфикс или откат, кто принимал решение, что вы добавляли в регресс или автотесты, чтобы баг не повторился;
- фича-флаги и постепенная выкатка: если были, это сильный пункт, потому что проверка на части пользователей тоже работа QA.
Цифры давайте свои и только те, которые можете объяснить: сколько релизов в неделю, сколько занимал регресс, сколько багов пришло с прода за квартал.
Если к проду вас не подпускали, скажите прямо и покажите, что понимали процесс: кто выкатывал, как вы узнавали о багах от поддержки, как воспроизводили их на стенде. Добавьте, что хотели бы участвовать больше, если это правда.
Где спотыкаются
Приносят STAR-историю с «критических багов стало меньше на 20%». Цифра без источника вызывает недоверие, а не уважение.
Приписывают себе всё подряд: и тестирование, и деплой, и мониторинг. На уточнении, кто нажимал кнопку отката, ответ рассыпается.
Рассказывают, что тестировали прямо на проде с реальными клиентскими данными, и подают это как плюс. Для интервьюера это сигнал о рисках, а не о смелости.