Есть ли в команде специалисты для полного цикла разработки и релиза?
Что проверяют
Как была устроена ваша прошлая команда и насколько вы самостоятельны: доводили ли вы задачу до продакшена или отдавали код дальше по цепочке. От ответа зависит, куда вы впишетесь: в команду с отдельными QA и DevOps или туда, где разработчик сам пишет тесты, Dockerfile и пайплайн. Следом обычно спрашивают, как проходил релиз и что вы делали в нём лично.
Как отвечать
Опишите состав и распределение ответственности на своём примере:
- кто был: аналитик или продакт, разработчики, QA, DevOps или SRE, дизайнер. Сколько человек и на сколько команд они делились;
- путь задачи: требования, код, ревью, тесты, релиз. Где оставались ручные шаги, а где работала автоматика;
- ваша зона: для Python-разработчика это обычно код и тесты на
pytest, миграции (Alembic или Django migrations), линтеры и проверка типов в CI (ruff,mypy), сборка образа, иногда деплой через GitLab CI или GitHub Actions в Kubernetes; - после релиза: кто смотрел ошибки в Sentry и метрики, кто дежурил, как откатывали.
Если отдельного тестировщика или DevOps не было, это не минус, а повод рассказать, что вы закрыли сами: например, настроили прогон тестов на каждый merge request или написали чек-лист выкладки. Если роли были, покажите, что не перекидывали задачу через забор: помогали QA воспроизвести баг, описывали миграции в merge request, участвовали в разборе инцидентов.
Цифры и примеры здесь нужны ваши собственные. Этот же вопрос полезно задать и компании в конце встречи: ответ покажет, сколько инфраструктурной работы достанется вам.
Где спотыкаются
Отвечают одним словом «да, все были» и упускают возможность рассказать о своём вкладе в релиз.
Приукрашивают: заявляют, что сами вели деплой, а на вопрос, как устроен пайплайн или как откатить миграцию, ответить не могут.
Жалуются на прошлую команду в духе «тестировщиков не было, всё падало». Сильнее спокойно описать ограничения и то, что вы сделали, чтобы релизы от них не страдали.