Какие были сроки проекта

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

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

Как отвечать

Возьмите один конкретный проект и расскажите по порядку, с реальными датами:

• масштаб и рамки: что делали (вынос сервиса из монолита на Go, новый gRPC API, переезд на другую очередь), сколько было людей, какой срок и откуда он взялся: внешний дедлайн, релиз партнёра, требование регулятора или внутренний план;
• оценка: декомпозиция, запас на неизвестное, что оценивали отдельно. В Go-проектах время часто уходит не на бизнес-логику, а на интеграции, генерацию кода из protobuf, нагрузочные тесты, профилирование через pprof и миграции данных;
• ход работ: промежуточные вехи, как отслеживали прогресс, когда увидели риск;
• отклонение: что пошло не по плану и что вы сделали. Сильные ходы: предупредить заранее, урезать объём до MVP, выкатить часть за фиче-флагом, перенести второстепенное;
• итог: уложились или нет, насколько отклонились, что поменяли в оценке следующих задач.

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

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

Рассказывают идеальную историю «сдали на две недели раньше». Без единого риска это звучит неправдоподобно, и интервьюер начнёт копать.

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

Перекладывают срыв сроков на менеджеров или заказчика. Лучше показать, что лично вы сделали, чтобы риск стал виден раньше.