Tell me about a time when you made an error in judgment.
Asked at:
Meta
Amazon
Oracle
Airbnb
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 a real mistake, own your role in it, and show sound judgment after the fact. They are usually less interested in the mistake itself than in your honesty, your reasoning at the time, and whether you built a durable learning loop. At higher levels, they also care about whether your judgment affected others and whether you improved the system, not just your own behavior.
“Describe a time you made a poor call at work. What happened?”
“What's a situation where your judgment was off, and how did you handle it?”
“Tell me about a decision you regret making on a project.”
“Have you ever realized you were heading in the wrong direction after making a call? Walk me through it.”
“Give me an example of a time you misjudged a situation at work.”
Key Insights
- Pick a real judgment error, not a disguised success or a harmless typo. The strongest answers show that you made a reasonable call with incomplete information, then recognized where your thinking was flawed.
- You need to explain your decision-making, not just the bad outcome. Interviewers want to see how you weighed tradeoffs, what signals you missed, and whether you can now spot similar situations earlier.
- Don't stop at 'I fixed it.' Show how your behavior changed afterward and how you know that change stuck, especially if you're interviewing at senior levels or above.
What interviewers probe atlevel
Top Priority
Show that you can explain what assumption or shortcut led you astray, not just that the outcome was bad.
Good examples
🟢The real issue was that I equated 'I can implement it' with 'it's the right way to do it,' and I had not thought enough about maintainability.
🟢I acted on one data point from a previous task and assumed the same pattern applied here, but the dependency surface was much wider.
Bad examples
🔴It was wrong because it caused bugs, so after that I was more careful.
🔴I picked the wrong approach and then my mentor pointed out a better one, so I switched.
Weak answers describe results; strong answers identify the flawed mental model that produced the result.
At junior level, the bar is simple but important: choose a genuine mistake and clearly own your part in it.
Good examples
🟢I underestimated how risky it was to change a shared module without asking for a review first. That was my call, and it created avoidable cleanup for the team.
🟢I assumed I understood the task because something similar had worked before, and I moved too quickly. The mistake was mine, not the process.
Bad examples
🔴I wouldn't call it an error in judgment, but my lead wanted one approach and I preferred another, and later we found out their way was a bit faster.
🔴The main issue was that requirements kept changing, so the work went off track. I had done what I was told, so there wasn't much I could have done differently.
Weak answers minimize the mistake or redirect blame; strong answers name the candidate's decision clearly and own its consequences without drama.
Valuable
Once you noticed the issue, show that you acted quickly, involved the right people, and helped clean it up.
Good examples
🟢I surfaced it quickly, wrote down what was affected, and worked with my teammate to undo the risky part before it spread further.
🟢I let the reviewer know exactly where my assumption had been wrong and took on the follow-up tasks to close the gap.
Bad examples
🔴After I realized it was a problem, I fixed my part and moved on because there wasn't much else to do.
🔴I told my lead about it and waited for guidance on what they wanted me to change.
Weak answers are passive or narrowly scoped; strong answers show urgency, transparency, and follow-through.
Example answers atlevel
Great answers
In my first few months on my team, I made a judgment call to update a shared helper function on my own because the change looked small and I wanted to move quickly. It passed my local tests, but it changed behavior for another workflow and created extra work for a teammate. I told my lead as soon as I realized what happened, helped revert the risky part, and then worked with the teammate to put in a safer version. What I got wrong was assuming that because I understood my use case, I understood all the use cases. Since then, whenever I touch shared code, I check who else depends on it and get a quick review before I commit to the implementation.
Early in my first mobile role I was rushing to prepare a stakeholder demo and hit an intermittent UI freeze that I couldn't reproduce reliably. Instead of flagging it and postponing the demo, I added a small sleep to the code to mask the race and forgot to remove it before a build went out; a subset of users then experienced app freezes. When it surfaced I immediately told my manager, worked with a senior engineer to roll back the release and fix the underlying race condition, and added an automated UI test plus a pre-demo checklist to prevent masking issues in the future. The mistake taught me that protecting my reputation with quick hacks can harm users and the team, so I now favor transparency and proper fixes over short-term polish.
Poor answers
One time I changed an internal utility and another part of the product had issues afterward. It wasn't a major problem because we caught it quickly, and cases like that happen when you're moving fast. I fixed the code and after that I was more careful with changes in that area. Overall it was a useful experience because it showed me how interconnected systems can be.
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 January, 2026
Meta
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.