Что будешь делать, если не укладываешься в дедлайн

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

Хороший короткий ответ можно построить так:

Если вижу, что не успеваю, я сначала уточняю причину и остаток работы. Потом как можно раньше сообщаю команде статус, риск и варианты решения. Например, можно сузить scope, перенести часть задач, попросить точечную помощь или согласовать новый срок. После завершения я разбираю, почему оценка не совпала с реальностью, чтобы в следующий раз раньше снять похожий риск.

Такая формулировка звучит спокойно. Вы не оправдываетесь, не вините других и не обещаете невозможное.

Дедлайн обычно упирается в три вещи: дату, объем и качество. Если один параметр зафиксирован, нужно честно обсудить два других. Например, если дата релиза жесткая, можно уменьшить scope. Но нельзя незаметно вырезать вещи, без которых сценарий становится опасным: loading, error, защиту от двойного submit, сохранение введенных данных, labels, фокус и проверку основного пути. Если scope обязателен, нужно обсуждать срок или помощь. Если не обсудить ничего, риск уйдет в качество. Появятся баги, плохой UX, пропущенные состояния ошибки, сломанная аналитика или неготовая мобильная верстка.

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

Если риск появился заранее:

Сейчас готов основной сценарий и часть UI-состояний. Риск в интеграции с API: обработка ошибок заняла больше времени, чем я ожидал. По текущей оценке нужно еще 1 день. Могу предложить два варианта: выпустить базовый сценарий в срок с понятным loading, error и защитой от повторной отправки, а не критичные edge cases перенести, либо сдвинуть срок на день и закрыть все состояния сразу.

Если вы уже опаздываете:

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

Детали нужно заменить на свои. Не выдумывайте проценты, баги или зависимости, которых нет. Лучше честно сказать меньше, но точно.

Представьте, что вы делаете форму оплаты или заявки. Верстка готова, но при интеграции выяснилось, что API возвращает несколько видов ошибок, а дизайн не описывает все состояния. Если молча доделывать до ночи, можно выпустить форму, которая не объясняет пользователю причину ошибки или теряет введенные данные.

Более безопасный ход: поднять риск сразу. Скажите, что базовая отправка работает, но нужно согласовать обработку ошибок и проверить сценарии: пустые поля, ошибка сети, повторная отправка, медленный ответ, мобильная верстка, фокус на поле с ошибкой и сохранение введенных данных. Дальше предложите выбор. Выпустить только базовый сценарий с понятным сообщением об ошибке, блокировкой повторного submit и доступным label. Или добавить один день на полную обработку состояний.

Такой пример хорошо подходит для интервью, потому что он связывает дедлайн с последствиями во фронтенде. Речь не просто про календарь, а про качество интерфейса и опыт пользователя.

Хороший ответ не заканчивается переносом срока. После завершения задачи стоит понять, почему оценка не совпала с реальностью. Возможно, вы не учли ревью, зависимость от API, проверку в браузерах, настройку аналитики, тестирование ошибок, доступность, обработку гонок запросов или согласование дизайна.

На интервью можно сказать так:

После задачи я бы коротко разобрал, где ошибся в оценке. Если проблема была в неизвестной технической части, в следующий раз начну с прототипа или spike-задачи. Если задержка была из-за зависимостей, раньше отмечу их в плане и добавлю буфер на согласование.

Это показывает рост. Вы признаете ошибку, но не застреваете в самообвинении.