Describe a time when you didn't think you were going to meet a commitment you promised.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you behave when reality starts to diverge from a promise you made. They want to see whether you notice risk early, take ownership instead of hiding, communicate clearly, and respond in a way that protects trust. For more senior candidates, this question also tests judgment about tradeoffs, scope management, and how broadly their decisions affect others.
“Tell me about a time you realized you were unlikely to deliver something when you said you would.”
“Describe a situation where a deadline or commitment you made started to slip. What did you do?”
“Have you ever had to tell someone you might not meet a promise you made at work?”
“Walk me through a time when a project was going off track against a commitment you had made.”
“Can you give me an example of when you saw early signs that you might miss a delivery date and how you handled it?”
Key Insights
- You do not get credit just for working harder when a commitment is at risk. Strong answers show that you diagnosed why the commitment was slipping and changed the plan, not just your hours.
- The key moment in this story is often when you realized the promise might be missed. Explain how early you recognized the risk and what you did immediately after that; veteran interviewers listen closely for whether you were proactive or merely reactive.
- Be honest about the commitment being genuinely at risk. Trying to turn a minor delay or a last-minute save into a big leadership story often backfires; a better answer shows credible pressure, clear ownership, and preserved trust.
What interviewers probe atlevel
Top Priority
A strong junior answer owns the problem without pretending you had total control over everything that caused it.
Good examples
🟢Even though part of the delay came from an external issue, I treated it as my responsibility to communicate the impact and help find the best next step.
🟢I had underestimated part of the work, and I was direct about that instead of framing it as bad luck, because I wanted the team to have an accurate picture.
Bad examples
🔴It was mostly because the requirements weren't clear, so there wasn't much I could really do besides keep working.
🔴The delay came from another person not getting me what I needed, so I just waited for them and explained that later.
Weak answers use causes as excuses; strong answers acknowledge causes while still owning the response.
You do not need executive polish at junior level, but you do need to be direct, timely, and clear about what the risk means.
Good examples
🟢I told my lead exactly what was blocked, what date was now at risk, and what help would unblock me fastest.
🟢When I realized I might miss my part of the work, I didn't soften it into vague status language; I said clearly that the commitment was at risk and what I needed to do next.
Bad examples
🔴I mentioned in standup that things were a little more complicated than expected, so people generally knew it might take longer.
🔴I sent a quick message saying I was still working through a few things and would share more when I had them fixed.
Weak answers communicate motion without clarity; strong answers make the risk and needed response easy for others to understand.
Valuable
Interviewers want to hear that this was not just a stressful story but a growth moment that changed how you work.
Good examples
🟢I started breaking my estimates into smaller steps and checking in earlier when one step took longer than expected.
🟢That experience taught me to test risky assumptions sooner, and since then I've used that habit on later tasks to avoid late surprises.
Bad examples
🔴After that, I just try to work faster whenever I have a deadline.
🔴The main thing I learned is that unexpected issues can happen on any project.
Weak answers offer generic lessons; strong answers describe a specific behavior change that plausibly prevents recurrence.
At junior level, you are not expected to make every tradeoff alone, but you should show you understood the available options and helped move toward one.
Good examples
🟢With my mentor, I separated must-have work from nice-to-have work so we could still deliver the core piece on time.
🟢We decided to postpone one lower-risk improvement and focus on the part that unblocked others, and I helped validate that this was the right tradeoff.
Bad examples
🔴I just kept trying to finish everything because I had already promised the full scope.
🔴Since the deadline was slipping, I rushed the remaining work so I could still say it was done.
Weak answers cling to the original promise or cut quality blindly; strong answers show thoughtful adjustment of scope, sequence, or quality with awareness of impact.
Example answers atlevel
Great answers
In my first year, I owned a small internal tool update that another engineer was waiting on before they could finish their part. A couple of days in, I realized I had underestimated how long it would take to understand the existing code, and one environment issue was slowing me down even more. I told my mentor that afternoon that I was unlikely to hit the date I had originally given and came with two options: either I could deliver the core change on time and leave one cleanup item for later, or we could move the whole task by a few days. We chose the smaller first version because it still unblocked the other engineer. I finished that piece on time, then came back and completed the cleanup work in the next sprint. After that, I started breaking tasks into smaller estimates and checking risky assumptions earlier.
As a junior mobile engineer at a small startup I promised product and sales that I would get a crash fixed before a big client demo later that day. Mid-morning I discovered the crash was caused by a platform-specific behavior that would take more than a few hours to rewrite, so I immediately messaged the PM and the account manager to explain the problem, what caused the delay, and two clear options: ship a temporary UI change that avoids the crash for the demo, or postpone the demo so I could implement a proper fix. We chose the temporary UI change so the demo could go ahead, and I documented the exact cause and the steps to reproduce it for the team. I then stayed late to finish the proper fix and the next morning rolled out the full solution, and afterwards I added a short release checklist and a simple automated check for that platform behavior so we’d catch it earlier next time.
Poor answers
I had a task where I thought I might miss the date because the codebase was more complicated than I expected. I kept working on it because I didn't want to raise concern too early, and I mentioned in standup that it was taking a bit longer. Near the deadline I let my lead know it probably needed more time, and we ended up pushing it out a few days. It worked out fine because I still got it done, and everyone understood that these things happen.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid September, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.