Бывают ли авралы на проекте
Что проверяют
Как вы относитесь к переработкам и умеете ли работать под давлением срока без паники и без героизма. Следом обычно спрашивают, что вы сделали, чтобы аврал не повторился, и где ваша граница.
Как отвечать
Отвечать стоит честно: авралы бывают почти везде, вопрос в частоте и в том, что вы с ними делаете. Каркас на своём опыте:
- ситуация: что стало причиной. Для фронтенда типичны релиз под маркетинговую дату, смена макетов за неделю до запуска, падение прода после деплоя;
- ваши действия: договорились с менеджером и дизайнером о срезе объёма, выкатили минимальную версию за feature-флагом, откатили релиз вместо ночной починки, не отказались от ревью целиком, а сузили его до критичных мест;
- результат: что успели и чем пожертвовали. Цифры нужны ваши собственные, например «из двенадцати экранов в релиз пошли восемь, остальные доехали через спринт»;
- выводы для процесса: заморозка макетов за спринт до релиза, смоук-тесты на Playwright перед выкладкой, разбор на ретро.
В конце обозначьте позицию: разовый аврал перед важным запуском нормален, постоянный режим пожара говорит о проблеме в планировании. Уместно спросить в ответ, как часто такое случается в этой команде и как компенсируются переработки. Это не каприз, а нормальная проверка компании.
Если опыта в коммерческой команде ещё не было, скажите об этом прямо и приведите близкий пример: сдача дипломного проекта, хакатон, дедлайн на фрилансе. Покажите, как расставляли приоритеты и что отрезали, а не как не спали.
Где спотыкаются
Говорят «у меня авралов не бывает, я всё планирую». Звучит неправдоподобно, а интервьюер слышит, что вы не работали в реальной команде.
Рассказывают героическую историю про три бессонные ночи. Для нанимающего это сигнал либо о слабом процессе, либо о человеке, который сам доводит задачи до пожара.
Жалуются на прошлого менеджера или заказчика и не делают выводов. Ответ без изменений в процессе выглядит так, будто следующий аврал случится точно так же.