Как видишь жизненный цикл задач и основные этапы работы над задачей
Что проверяют
Как вы на самом деле работаете в команде: доводите ли задачу до результата в проде или считаете её готовой, когда код написан. Следом часто спрашивают, что вы делаете, если требования неясны или задача оказалась вдвое больше оценки.
Как отвечать
Рассказывайте путь одной задачи в вашей команде, с вашими инструментами и статусами, а не жизненный цикл ПО из учебника. Каркас для Python-разработчика:
- прояснение: читаю задачу, уточняю критерии приёмки и граничные случаи у аналитика или продакта до начала работы. Большую задачу делю на части, которые можно выкатить по отдельности;
- оценка и план: оцениваю, проговариваю риски, при необходимости пишу короткий дизайн, например схему миграции или контракт API;
- разработка: ветка от
main, код вместе с тестами наpytest, проверкиruffиmypyчерезpre-commit, миграции Alembic или Django, совместимые с работающей версией приложения; - ревью: небольшой pull request с описанием, что и зачем изменено, и ответы на замечания;
- CI и выкладка: зелёный пайплайн, выкладка на стенд, проверка тестировщиком, релиз на прод, для рискованных изменений под фича-флагом;
- после релиза: смотрю ошибки в Sentry и метрики, закрываю задачу, когда изменение работает у пользователей.
Подкрепите это эпизодом: задача, где вы заранее нашли пробел в требованиях, или случай, когда вы вовремя сказали о срыве оценки. Если опыт пока небольшой, честно опишите процесс на текущем месте или в учебном проекте и скажите, что из этого вы уже делаете сами, а что пока видели со стороны.
Где спотыкаются
Пересказывают водопад из учебника: сбор требований, дорожная карта, поддержка. Интервьюер спрашивал про вашу задачу, а не про методологию.
Заканчивают историю на «написал код и отдал в тестирование». Без тестов, ревью и проверки после релиза это выглядит как работа до передачи, а не до результата.
Молчат про коммуникацию. Когда требования поменялись или оценка поплыла, ценится, что вы сказали об этом сразу, а не в день дедлайна.