Что делал при понимании, что не успеваешь в сроки

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

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

Как отвечать

Рассказывайте по конкретному случаю, по шагам:

• как заметили: ежедневная сверка сделанного с оставшимся временем, а не ощущение в последний вечер;
• где ушло время: внешний сервис отвечал не так, как в документации, требования доуточнялись по ходу, миграция данных оказалась дороже кода;
• что сделали сами: вырезали необязательное, разбили поставку на части, выкатили под фича-флагом выключенным, договорились о временном решении;
• когда и кому сказали: в тот же день, когда отставание стало видно, причём не просто «не успеваю», а с вариантами: урезать объём, сдвинуть дату, забрать часть задачи;
• чем кончилось: что уехало в следующий релиз и как это прожили.

Полезно добавить, как вы даёте оценки сейчас: диапазон вместо одной цифры и явный список допущений.

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

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

Отвечают «сидел ночами и всё-таки успел». Переработка как единственный инструмент читается не как надёжность, а как неумение управлять объёмом, и следующий вопрос будет про то, что произойдёт в следующий раз.

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