Failure & growth
How to answer: “Tell me about a time you missed a deadline”
An accountability and communication test. Show you saw the slip early, communicated it proactively, and managed the fallout well.
Why it is asked
What this question is really testing
What this question really probes is how you behave when a commitment is slipping. Missing a deadline occasionally is normal; the difference between a strong and a weak engineer is whether the stakeholders found out from you, early, with options, or found out at the deadline with excuses. Proactive communication is the whole signal here.
Tell a story where you recognised the slip before it was a surprise, raised it with the people affected, and brought choices rather than just bad news (cut scope, move the date, add help). Then show how you reduced the chance of it recurring. Owning the cause without wallowing in it is the balance to strike.
Do not pick a deadline you missed through pure negligence, and do not pick one where you secretly think it was someone else's fault. The best stories show good judgment under a constraint that genuinely could not all be met.
The signal
What interviewers listen for
- You saw the slip coming and did not let it become a surprise.
- Proactive, early communication with the people affected.
- Options offered, not just an apology: scope, time, or resources.
- A change that lowered the odds of it happening again.
Worked example
A STAR answer you can adapt
Scenario: Engineer on a feature with hidden complexity. Read it for the shape, then swap in your own story.
Situation
I committed to a feature in a two-week sprint, but a week in I hit integration complexity I had badly underestimated.
Task
There was no way to ship the full scope safely by the date.
Action
Rather than push and hope, I flagged it to my PM and lead at the start of week two with three options: ship a smaller v1 on time, take three more days for the full version, or pull in a second engineer. I recommended the smaller v1 and laid out exactly what would be cut.
Result
We shipped the v1 on time and the full version a few days later. My PM said the early heads-up was what made it a non-event. I also started padding estimates for anything with an unfamiliar integration, and my estimates have been far more reliable since.
Answer skeleton
Fill-in-the-blank template
I committed to [deliverable] but hit [unforeseen complexity] partway. I flagged it early with [options]. We chose [option], shipped [outcome], and I now [prevention] so it is less likely to recur.
Avoid these
Common mistakes
- A story where stakeholders only learned at the deadline.
- Blaming the estimate, the requirements, or other people.
- Bringing only an apology and no options.
- No follow-through to prevent a repeat.
By role
How the answer shifts by role
Engineering
Underestimated complexity is the most credible cause. Emphasise the early flag and the scope-cut option.
Product management
Show how you renegotiated scope with stakeholders and protected the most important outcome.
Engineering management
Demonstrate how you got ahead of the slip across a team and communicated up before it became a fire.
Be ready for
Likely follow-up questions
- At what point did you know you would miss it?
- How did the stakeholders react to the early warning?
- How have your estimates changed since?
Last reviewed by the site editor: June 2026
Keep going
Related behavioral questions
More questions from the same territory, each with its own worked answer.
Turn prep into an offer
Behavioral rounds are only half the loop. See the technical and behavioral questions for your exact role, and when an offer lands, check it is competitive with the salary comparison tool.