Tell me about a time you missed a deadline.
answer
- name the date and who counted on it
- the early signal you noticed
- escalate with options, not just bad news
- say how late it actually was
- the estimating change that stuck
basics
~20 sProbes early communication and realistic re-planning, not perfection. Give one real slip you owned, the moment you first knew, the options you brought when you escalated, how late it actually was, and the estimating habit you changed.
how to answer
5 beats- the commitment and who was counting on itOne or two sentences: what you promised, to whom, and by when. Keep situation and task to roughly fifteen to twenty percent of your airtime — the setup is not where the signal lives.
- the moment you knew the date was at riskName the point in the work and the signal that revealed it, not the due date. If you delayed before speaking up, say so; owning that gap is worth more than pretending it did not exist.
- how you escalated and what you proposedThis and the next beat are the bulk, around sixty percent of your airtime. Describe the update you sent and the two or three costed options you attached, and be clear about which one the decision-maker chose.
- the revised plan and what actually shippedRebuild the plan from real evidence — measured throughput, remaining scope — not from a wish. Then say plainly how late the final delivery was, in days or cycles, and what state it shipped in.
- the estimation habit you changedClose with roughly twenty percent of your airtime on the lesson, expressed as a mechanism you still use. One specific change, ideally with evidence it held on a later commitment.
your answer
5 story prompts- Pick a date you personally committed to and missed, ideally within the last two years.
- Write down the day you first knew it was at risk and the day you told someone.
- Name the mechanical cause of the bad estimate in one sentence, without blaming anyone.
- Have one number ready for how late it shipped: days, weeks or cycles.
- Note the estimating change you kept, and one later commitment where it held.
draft and rehearse your own answer in a learn session
go deeper
This probes ownership and communication under schedule pressure. Interviewers assume everyone slips a date eventually; what varies is detection latency, whether bad news arrives with options attached, and whether the estimation error was diagnosed rather than excused. A strong answer proves you are someone a stakeholder can plan around even when the plan changes.
I was a contributor on an open-source analytics dashboard project, and I signed up to build a query-caching layer that the maintainers wanted in the next milestone release. I estimated four days. It ran to eleven. The cause was estimation, not effort. I sized the caching logic itself and ignored the fact that each of the seven panel types read data through its own code path, so every one of them needed touching separately. I could see it on the third day, when the cache was working and the first panel still went straight to the database. That is the part I would change. I sat on it for two more days hoping to catch up, because admitting the miss felt worse than the miss. When I finally posted in the milestone thread, I wrote what was done, what was left, and two options: ship caching for the two heaviest panels now, or hold the whole change for the release after. The maintainer took the partial ship. Those two panels went out and median load on the busiest dashboard came down from 6.2 seconds to 3.4. The remaining panels landed six weeks later. What stayed with me is those two silent days. Now, the day an estimate starts drifting, I say so — and I bring the options with it, so the update is a decision for someone rather than just bad news.
Junior scope done well: one owned task, an honest mechanism for the estimate error (fan-out across panel code paths), and a specific result. The two silent days are volunteered rather than hidden, which is where the ownership signal sits. It would downlevel if the delay were blamed on unclear requirements or if no number for the slip appeared.
I maintained the charting layer of an open-source analytics project and told the maintainers a rendering rewrite would land in the milestone at the end of the quarter. It slipped by two milestones, and I was the one who had set the date. The work spread across nine contributors, most of them volunteers with a few hours a week. My error was pricing the engineering and not the coordination: I assumed review turnaround of about a day and it ran closer to five, and three contributors went quiet mid-way with nothing handed over. Once the burn-up flattened, around seven weeks in, I stopped guessing. I recut the remaining plan from the actual merge rate rather than the original estimate, which put completion four months out instead of two. I brought the maintainers that arithmetic with a proposal attached: split the rewrite so the renderer swap could ship on its own, and put the interaction work behind an opt-in setting. The renderer half made the original date and took the heaviest dashboard from 11.8 seconds to 2.9. The interaction work arrived two milestones late, and that is the miss. Since then I size volunteer throughput from the previous cycle's merged-change rate instead of from how many names are on the list, and I publish the burn-up so the maintainers can see a slip coming before I have to announce one.
The signal here is the renegotiation: a plan rebuilt from measured merge rate, a split that let half the value land on time, and a durable estimating input afterwards. Naming coordination rather than difficulty as the cause is what makes the diagnosis credible. It would downlevel if the answer stopped at confessing the slip without the recut plan.
Own the piece you committed to and be honest about the gap between your estimate and the work. Show that you raised it to someone rather than hoping to catch up quietly, and name one concrete change to how you size work now.
The story should include the renegotiation, not just the confession. Show the revised plan you built from actual throughput, the options you put in front of the person holding the date, and which one they chose.
Expect to be judged on whether the slip was visible before it landed. Talk about the signal you were watching, how you kept the stakeholder ahead of the bad news, and the trade you made between scope, date and quality.
Frame the miss as an estimation-system problem, not a personal one. What in how the group commits produced the slip, and what mechanism did you leave behind so that later slips surface early without depending on your attention?
saying these in an interview costs you the question
- Blaming changing requirements without naming your own estimation error
- Discovering the slip on the due date and not before
- Announcing the delay with no revised plan or options attached
- Never saying how late it actually was
- Presenting overtime heroics as the resolution
- We-language throughout, with no decision the speaker personally made
- When did you first suspect the date was at risk?Answer with a point early in the work and the signal that gave it away, not with the due date. Say what you were tracking that made it visible, and how many days passed between suspecting and telling someone. If that gap was long, own it plainly and say what you do now instead.
- What options did you give the person holding the date?Name two or three real levers with their costs, and be clear about which you recommended and which they chose. Interviewers listen for whether you handed over a decision or only handed over a problem. If there were genuinely no options, explain the constraint that removed them.
- How did the people counting on that date react?Be honest, including if the reaction was cold. What matters is whether the working relationship survived and what you did to rebuild predictability afterwards. A short line about how the next commitment to those same people went is stronger than insisting everyone understood.
- What would you estimate differently now?Give one mechanism, not a resolution to be more careful. Something like sizing from measured throughput rather than headcount, splitting anything past a certain size before committing, or pricing review and integration time explicitly. One specific change beats three vague intentions.
### The prompt family This one arrives in several wordings, and they are the same question: *tell me about a time you missed a deadline*, *tell me about a commitment you could not keep*, *when have you had to tell someone their date was moving*, and the softened *walk me through a project that ran late*. A few interviewers ask it in the negative — *have you ever shipped something late?* — where saying "no" is a losing move: it reads as either inexperience or as a memory edited for the room. Everyone with a few years of delivery behind them has slipped a date. The interesting variable is what you did between the moment you knew and the moment everyone else knew. ### What is actually being scored Three things, roughly in this order. **Detection latency.** How long between the first honest signal and your escalation. A candidate who says "about a third of the way in, the burn rate told me the estimate was wrong, and I raised it that week" is describing a professional habit. A candidate whose story starts at the due date is describing a person their manager cannot plan around. **The shape of the escalation.** Bad news delivered alone is a complaint. Bad news delivered with two or three costed options — cut this, move that, add a body here — is a decision handed to the person entitled to make it. Interviewers listen specifically for whether you proposed, or only reported. **Whether the estimate was diagnosed.** "It took longer than we thought" is not a cause. Causes are things like: the work fanned out across more call sites than the estimate assumed, review turnaround was four times the assumed rate, an unowned dependency was assumed to be free, or the estimate priced the code and not the coordination. Naming the mechanism is what separates an anecdote from a lesson. ### Weak versus strong on the same facts A weak version: *We had a tight deadline, requirements kept changing, and we ended up delivering two weeks late, but the client was happy in the end.* Passive throughout, no owner, no number, and the reflection is that someone else caused it. A strong version of the identical episode: *I owned the date. I sized the work at nine days and it ran to twenty-three, because I priced the feature and not the six integration points it touched. I flagged it on day six with the revised arithmetic and two options; we cut the two lowest-value integrations and shipped eleven days late instead of the fourteen the original plan implied.* Same slip, completely different candidate. ### Evidence that carries weight A specific number for how late it was. A specific mechanism for why. A named artefact from the escalation — a thread, a revised plan, a re-cut milestone. And a durable change afterwards: a different estimating input, a standing check-in, a burn-up published where the stakeholder can see it before you have to say anything. ### How the bar moves Below mid-level, owning the miss cleanly and escalating without being dragged is enough. From mid-level up, the interviewer wants the renegotiation itself — which lever you chose, what it cost, who agreed. At senior and beyond, the story is expected to end in a mechanism rather than a resolution: the practice that means the next slip is visible earlier, to more people, without you being the one who noticed.