There is a particular silence after "tell me about a time you missed a deadline". Candidates hear an accusation and start defending themselves before they have even picked an example. That instinct is the trap. The interviewer wants to know what you do in the two weeks before a date slips, because that is the part of the job they cannot observe until they have already hired you.
It is one of the more operational behavioural questions. It sits next to the broader "tell me about a time you failed", but it is narrower: planning, estimating, and telling people things they do not want to hear, early.
What the interviewer is actually testing
Did you see it coming? Anyone notices a deadline on the day it passes. What matters is whether you spotted the drift at 40 per cent through, or whether you were still reporting "on track" on the Thursday before a Friday delivery.
When did you escalate, and to whom? A late project everyone knew about three weeks in advance is an inconvenience. A late project that surprises your manager on the deadline day is a trust problem.
Do you own it without falling apart? There is a narrow band between blaming everyone else and flagellating yourself. Hiring managers are wary of both.
What did you change afterwards? Not a vague resolution to communicate better. A concrete change in how you estimate, track or report.
Notice what is not on the list: whether you have a spotless record. Nobody believes that, and nobody is hiring for it.
Why "I have never missed a deadline" is the worst possible answer
It is the answer that most reliably damages a candidate, and it usually comes from people trying to look strong.
It signals one of three things, none of them good. Either you have never worked on anything with real dependencies and genuine uncertainty, which caps the level they can hire you at. Or you have missed deadlines and are not being straight, which makes everything else you say slightly suspect. Or you have protected your record by padding every estimate and quietly descoping work, a much more expensive habit than the occasional honest slip.
Experienced interviewers will not argue. They will move on and mark it down. If you feel yourself heading there, stop and look harder. You have an example.
Choosing the example
- Real, but not catastrophic. A three-week slip on an internal migration is fine. A missed regulatory filing that cost the business a fine is a different conversation, and rarely one you want in 45 minutes.
- Not one where the villain is a colleague. Even if a teammate genuinely dropped the ball, building the answer around their failure reads as deflection. Mention the dependency; keep the story on your response.
- Not last month at your current job, if it is still raw. If you are still annoyed, it shows in your voice. Pick something eighteen months old that you can treat as a case study.
- Ideally one where the recovery is the story. The strongest versions are barely about the miss. They are about renegotiating scope and landing something usable on a date you set yourself and then hit.
- Not trivial. "I sent a status update a day late" reads as evasive, and the interviewer will simply ask again.
STAR, weighted towards the back half
Keep Situation and Task short - the setup is not what is assessed - and spend most of your airtime on Action and Result. For a two-minute answer: twenty seconds of context, ten on what you owed and by when, sixty to seventy on what you did once you knew it was slipping, twenty on the outcome. Inside the Action, the sequence that lands is always the same: how you noticed, when you told people, what you proposed rather than merely reported, and how you delivered the reduced version.
The detail almost everyone omits
Most candidates describe the miss and jump straight to the lesson. They skip the middle: the moment they told someone.
Say it explicitly. Name the day, the person, and what you asked for. "On the Tuesday of week three I told our head of ops we were going to be about ten days late, and I brought two options rather than just the bad news." That sentence does more for you than a paragraph of reflection, because it proves the behaviour instead of claiming it.
If you cannot remember when you escalated, better to find that out before the interview than during.
Three answers that work
Junior: the monthly claims report
My first proper job was junior analyst at an insurance broker, and one of my regular tasks was the monthly claims report for the leadership meeting - always due on the third working day.
>
In February the claims system got upgraded and the export I'd been using just wasn't there any more. I spent a day and a half trying to rebuild it myself, partly, honestly, because I didn't want to look like I couldn't handle my own report. On the morning of the second working day I went to my manager: I'm not going to make the third, I need until the fifth, and here's what I can give you meanwhile - I'd pulled the four headline numbers by hand so the meeting wasn't empty.
>
She was fine about it. What she said was that she'd rather have known on day one. After that I started dry-running the export three days out instead of the day before. Small thing, but it caught two more breakages over the next six months and neither was late.
Mid-level: the project that slipped three weeks
I was product manager on a payments integration - replacing our old checkout provider, live before the November peak. Eight weeks, four engineers.
>
Three weeks in I noticed our sandbox tickets were taking roughly twice as long as estimated, because the provider's test environment kept resetting. The arithmetic came out at three weeks over. I could have waited for more certainty, but I raised it at that week's steering call with two options: push to early December and miss peak, or cut stored cards from phase one and go live on time.
>
We took the narrower version. Stored cards shipped in January. What I'd do differently is the estimate itself - I built it from the provider's documentation rather than from a spike. Since then we spend the first three days of any integration on a throwaway prototype before committing to a date. On the next two projects our estimates were within a week.
When the delay came from outside: the dependency
I was running a website rebuild for a client at an agency in Manchester. Content sign-off sat with their legal team, with a two-week review window written into the contract.
>
Legal took five weeks. Nothing I could do about that directly, but I decided early that managing the delay was still mine. In week three I wrote to the client's marketing director and said plainly: eleven pages outstanding, at this rate we launch three weeks late, here are the three pages actually blocking the build versus the eight we can publish after go-live. I told my own account director the same day.
>
We launched two weeks late rather than five, with a reduced page set. What changed afterwards was the contract template - review windows now have a named approver and a hard date, and if it passes we launch with placeholder copy on non-critical pages.
Three levels, one shape: noticed early, told someone with options attached, delivered something, changed a process.
The follow-ups you should expect
- "Why didn't you flag it sooner?" If you were slow, say so, with the real reason. "I wanted to fix it myself first" is very human and interviewers hear it constantly. Follow it with what changed.
- "How did your manager react?" They are checking the story holds up. Do not paint them as a monster.
- "What would you do differently?" One specific thing. The list version sounds rehearsed.
- "Has it happened again?" If yes, say so and explain what was different. "Once, but I flagged it in week two instead of week five" shows the improvement rather than describing it.
- "How do you estimate now?" Have an actual method: spikes, historical velocity, buffers on external dependencies.
If you truly cannot think of an example
If you are early in your career and have never owned a delivery date, use a study project, a volunteer commitment or a dissertation, and say up front that it is not from work. Interviewers accept this from juniors far more readily than candidates expect.
If you have a decade of experience and nothing comes to mind, you are not looking hard enough. Go through the last three projects and ask a different question: not "did I miss a deadline" but "did anything ship after the date we first told someone". That usually produces two or three candidates within a minute.
What you must not do is invent one. Fabricated examples collapse under follow-ups, because invented stories have no texture - no specific Tuesday, no costed option, no awkward conversation.
Answers that sink the interview
- Blaming. "The developer didn't deliver." Even when true, it tells the interviewer what you will one day say about their team.
- Minimising. "It was only two days and nobody noticed." If it did not matter, why is it your example?
- "The client changed the scope", full stop. Scope changes constantly. The question is what you did next.
- Trivial. A late expenses claim reads as answering without answering.
- The confession spiral. Long, guilty, self-critical. It makes the interviewer uncomfortable and raises a separate question about how you take criticism.
- Too perfect. "I missed it, but it turned out better." Nobody believes a miss with no cost attached.
Say it out loud twice beforehand. Not to memorise it - the aim is to have the dates and numbers available, and for the rest to sound like a person remembering something, which is exactly what it is.