Tell me about a time when you made a bad decision.
Asked at:
Amazon
Oracle
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess whether you can recognize and own a real mistake without becoming defensive or evasive. They want to see your judgment under uncertainty, how you responded once the mistake became visible, and whether you turned the experience into a durable change. At higher levels, they also look at whether your decision quality matched the scope of your role and whether you reduced the chance of similar mistakes for others.
“Describe a time you made the wrong call. What happened?”
“What's a decision you regret at work, and how did you handle it?”
“Tell me about a time your judgment was off on an important situation.”
“Can you give me an example of a call you made that didn't work out?”
“Have you ever pushed a direction that turned out to be the wrong one?”
Key Insights
- You do not need a catastrophic failure. A strong answer is a legitimate bad decision with meaningful consequences, clear ownership, and a credible recovery and learning loop.
- You should explain why the decision seemed reasonable at the time. Interviewers are testing judgment, not just whether you can label something a mistake after the fact.
- Do not stop at 'I fixed it.' Show what changed in how you make decisions now, and for senior candidates, how you changed team or organizational behavior as well.
What interviewers probe atlevel
Top Priority
Pick a real mistake you personally influenced and name your role in it plainly.
Good examples
🟢I chose to skip a few edge cases because I wanted to hit the deadline, and that was my call.
🟢My lead trusted my estimate, but I was the one who said the simpler approach was safe when I hadn't checked enough.
Bad examples
🔴The decision went badly because the requirements changed, so there wasn't much I could have done.
🔴I guess my mistake was caring too much and moving too fast, but overall it was the right call.
Weak answers hide behind circumstances or turn the mistake into a virtue; strong answers clearly identify the candidate's own flawed choice.
Explain the judgment error, not just the bad outcome.
Good examples
🟢I optimized for finishing quickly because I was nervous about missing the deadline, and I didn't realize the missing validation would affect real users.
🟢I assumed a pattern from a previous task applied here, but I hadn't checked whether the data shape was actually the same.
Bad examples
🔴I picked the wrong approach because I didn't think it would be a problem.
🔴I just moved ahead since that seemed fastest and we could always fix it later.
Weak answers are shallow and make the decision sound careless; strong answers reveal a plausible thought process and a specific blind spot.
Show that you acted quickly, communicated clearly, and helped repair the damage.
Good examples
🟢As soon as I saw the problem, I told my lead, wrote down what I knew, and helped test the safer fallback.
🟢I first contained the issue for users, then worked with a teammate to identify every place the decision had affected.
Bad examples
🔴Once the issue showed up, I waited until the next team sync so we could discuss it together.
🔴I reverted part of it and then mostly moved on since the main problem was fixed.
Weak answers are passive or narrow; strong answers prioritize containment, transparency, and follow-through.
Valuable
A junior story can be small in scope, but it should still have real consequences and clear personal ownership.
Good examples
🟢I chose a shortcut in a feature I owned, and it caused incorrect results for a small group of users until we fixed it.
🟢I gave an overconfident estimate on a task, which blocked a teammate's work and forced us to replan the week.
Bad examples
🔴I once picked the wrong color theme for an internal dashboard and had to update it.
🔴I spent a little too long on a task because I wanted it to be cleaner.
Weak answers are trivial or low-stakes; strong answers are modest in size but materially meaningful.
Example answers atlevel
Great answers
In my first few months on my team, I made a bad decision on a reporting feature. I assumed the input data would always be complete, so I skipped some validation checks to finish before our sprint demo. After release, a few customers saw incorrect totals, and I realized the shortcut had been my call. I told my lead right away, helped disable the affected path, and then worked with another engineer to add the missing checks and test the edge cases we had missed. What I learned was that when I'm under deadline pressure, I'm prone to treating assumptions as facts, so now I write down the risky assumptions and review them before I commit to an approach.
In my second month at a small e-commerce startup, I made a bad decision to run a database migration I had written by myself during the workday because I didn't want to wait for the senior engineer who normally handles deployments. I underestimated a foreign-key cleanup and pushed the migration straight to production, which caused a cascade of errors on a product page for a few hours until customers reported it. I owned the mistake immediately, rolled the migration back with help from the on-call engineer, and stayed late to create a safe re-deployment plan and test it on a staging copy. Afterward I documented a migration checklist, added a policy to schedule schema changes during low-traffic windows, and started asking a peer to review any deployment that touches the database. The lesson I took away was that trying to look capable by avoiding help can cause bigger problems than the brief inconvenience of asking for a review.
Poor answers
One time I chose a faster way to build a small feature, and later QA found a couple issues. It wasn't a huge deal because that's what QA is for, and we fixed it before the full launch. I think it was still the right call because we kept moving and didn't miss the sprint. In general, I like to move quickly and adjust if something comes up.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early March, 2026
Amazon
Manager
Early February, 2026
Oracle
Senior
Late November, 2025
Meta
Manager
Hello Interview Premium
Your account is free and you can post anonymously if you choose.