Search
⌘K

Tell me about a time where you failed to deliver a project on time

Asked at:

Amazon

Amazon

Meta

Toast

Toast


Try This Question Yourself

Practice with feedback and follow-up questions

What is this question about

Interviewers use this question to assess how you handle missed commitments when things do not go to plan. They want to see whether you can talk honestly about a failure, explain your role in it without being defensive, and show a credible recovery and learning loop. For more senior candidates, it also tests whether your planning, communication, and mitigation behaviors match the scope you are expected to operate at.

  • Describe a project where you missed a deadline. What happened?

  • Can you tell me about a time your team or project slipped past the original schedule?

  • Walk me through a situation where you realized you were not going to hit a committed date.

  • Have you ever had to explain that something would not ship on time? What did you do?

  • What's an example of a delivery commitment you did not meet, and how did you handle it?

Growth
Ownership
Communication
Scope

Key Insights

  • You do not get much credit for saying the deadline was missed because of external factors alone. Show what you owned: how you noticed risk, what you did when the plan started slipping, and what you would now do differently.
  • Do not pick a fake failure where the deadline moved for harmless reasons or where the project was not important. A strong answer involves a real miss with consequences, plus a thoughtful explanation of why your original plan was wrong.
  • Many candidates focus on the miss itself and forget the recovery. You should make clear how you communicated the slip, how you reduced downstream damage, and what changed in your behavior afterward so the story ends with growth, not just apology.

What interviewers probe at
level

Top Priority

At junior level, you are not expected to run the whole plan, but you are expected to notice when your work is at risk and respond responsibly.

Good examples

🟢After I realized my first approach was taking too long, I asked for a quick review and we chose a simpler implementation to protect the date.

🟢I broke the remaining work into smaller pieces, shared what was still uncertain, and got help on the riskiest part first.

Bad examples

🔴I kept trying different fixes because I thought I was close, so I waited until the end of the week to mention I was blocked.

🔴Once it started slipping, I just worked longer hours and hoped to catch up.

Weak answers show passive hope or hidden struggle; strong answers show early signal detection and practical mitigation.

A good junior answer ends with a believable behavior change, not just 'I worked harder next time.'

Good examples

🟢After that project I started breaking my work into smaller checkpoints and checking assumptions with my lead earlier, which helped me catch risk sooner on later tasks.

🟢I asked for feedback on how I plan my work and began giving earlier updates when something felt uncertain, which improved my reliability on the next project.

Bad examples

🔴After that I just started putting in more time when projects felt tight.

🔴The lesson was mostly to be more careful with estimates.

Weak answers offer generic intention; strong answers show a concrete change in behavior that plausibly prevents recurrence.

At junior level, interviewers mainly want to hear that you can admit your contribution clearly instead of hiding behind process or senior people.

Good examples

🟢I underestimated how long the debugging and testing would take, and I kept assuming I was almost done instead of surfacing that risk early.

🟢There were outside factors, but my part was that I did not ask for help when I got stuck for several days, which made the delay worse.

Bad examples

🔴The project slipped because the requirements kept changing, so there really wasn't much I could have done other than wait for clearer direction.

🔴I was depending on my mentor for reviews, and since they were busy the timeline just moved out.

Weak answers treat the delay as something that happened to them; strong answers identify a real decision or behavior they personally controlled.

You do not need executive polish at junior level, but you do need to show that you surfaced risk early and clearly.

Good examples

🟢I told my lead as soon as I saw I might miss the date, explained what I knew and what I was still figuring out, and asked for help on options.

🟢I gave a concrete update on what was done, what was blocked, and what timeline I now thought was realistic.

Bad examples

🔴I did not want to bother anyone until I had fully diagnosed the problem, so I waited to share an update.

🔴I mentioned that things were slower than expected, but I did not really quantify what that meant for the deadline.

Weak answers hide uncertainty until late; strong answers communicate early enough for others to help or adapt.

Example answers at
level

Great answers

In my first year, I was assigned a small internal tool feature that was supposed to ship by the end of the sprint, and I missed that date by about a week. I had underestimated how long it would take to understand one part of the existing code, and I spent too long trying to solve it on my own because I thought I was close. Once I realized I was slipping, I told my lead exactly what was blocked and we paired on a simpler approach that cut some nonessential polish from the first version. We shipped the core functionality the next week, and afterward I started breaking my work into smaller checkpoints and asking for a quick review earlier when something felt uncertain. That helped me avoid the same pattern on later tasks.

At my previous job I was responsible for a small new onboarding flow for our mobile app that was supposed to go out with a marketing push; I missed the ship date by a few days because I had misunderstood the product acceptance criteria and built it in a way that didn’t meet the design handoff. As soon as QA flagged the gap, I owned the mistake, explained to the product manager and marketing team exactly what was wrong and how long a fix would take, and we agreed to delay the public launch while I focused on the correct behavior. I pushed an interim update to a small beta group so we could collect early feedback and avoid a wider problem, then finished the full fix and verified it with a short demo to product and design. Afterward I created a short pre-release checklist and started walking features through a quick design/dev review before implementation to make sure acceptance criteria were clear. That change has helped me avoid similar misses and keeps the team aligned on what “done” actually means.

Poor answers

I missed a deadline on a feature because the requirements changed a few times and the codebase was more complicated than expected. I kept working on it until I had a complete solution, and then I updated my lead that it would take a bit longer. We still got it out, just not in the original sprint. Situations like that happen when you're new and still learning a large system.

Question Timeline

See when this question was last asked and where, including any notes left by other candidates.

Mid January, 2026

Meta

Senior

Late November, 2025

Meta

Staff

Mid October, 2025

Meta

Manager

Your account is free and you can post anonymously if you choose.