Как работать с горящими сроками и сжатыми спринтами

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

Как вы ведёте себя, когда объём работы не помещается в срок: молча перерабатываете, режете качество или договариваетесь о приоритетах. Следом обычно спрашивают, что вы делаете, если за несколько дней до дедлайна понимаете, что не успеваете.

Как отвечать

Опирайтесь на свой случай и называйте реальные сроки и объём. Каркас:

• что зафиксировано: срок, объём или качество. Все три одновременно не удержать, поэтому первым делом выясняют, чем можно пожертвовать;
• сокращение объёма: вместе с продуктом делите задачу на обязательное и желательное (MoSCoW подходит) и договариваетесь о минимальной версии. Фронтенду тут есть что предложить: простое состояние вместо анимации, готовый компонент дизайн-системы вместо кастомного, адаптив под основные ширины без редких случаев;
• параллельная работа: не ждёте бэкенд, а согласуете контракт API и работаете на моках, например через MSW. Когда эндпоинт готов, подключение занимает часы, а не дни;
• выпуск по частям: feature flags позволяют влить недоделанное в main и включить, когда готово;
• что не режете: типизацию, ревью и проверку критичного сценария. Всё, что сознательно отложили, записываете в бэклог отдельными задачами;
• коммуникация: о риске срыва говорите, как только его видите, а не в день релиза. «Успеваю А и Б, В переносим на следующую неделю» лучше тихой надежды.

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

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

Рассказывают про героизм: работал ночами и выходными. Это история о том, что планирование не сработало, а не о навыке.

Говорят, что успели всё в полном объёме без компромиссов. Опытный интервьюер в это не верит и спросит, что именно отложили.

Не упоминают последствий. Сильный ответ показывает, что было после релиза: какие баги всплыли и когда вернулись к отложенному.