INTERVIEW QUESTION
Tell me about a time you failed or made a mistake: how to answer in an interview
Choose a real failure or mistake, and show what you did about it, both at the time and afterwards.
“Tell me about a time you failed” and “Tell me about a time you made a mistake” are among the most common behavioral interview questions. They're also the ones people most want to dodge, because it feels like handing over a reason not to hire you.
Interviewers see it differently. An engineering interviewer on Reddit says it isn't a trick question: anyone who has worked for more than a few years has made a big mistake. They want to know what it was, how you dealt with it, and how you make sure it won't happen again.
Both wordings need those same three things: your part in what went wrong, what you did straight away, and what you do differently now. The mistake version puts more weight on the first.
Choosing a failure or mistake that won't cost you the job
Most of the work is choosing the example. It has to be big enough to be real, but not so close to the heart of the job that it makes the interviewer doubt you can do it.
Both risks are real. A panel interviewer for product managers treats a small slip, such as a wrong calculation that had to be explained, as a cop-out showing a lack of self-awareness or accountability.
The opposite risk shows up in the same thread. A product manager says two companies turned them down after they described not checking whether a feature their team ran was having any effect. The reason given was weak core product skills.
Before you choose, check the example against these:
- You caused part of it. Something you decided, missed or assumed, not only bad luck or someone else's error.
- It mattered. A customer, a deadline, a decision or a team was affected.
- It doesn't suggest you can't do the job. A one-off error in your main skill can work if you caught it and changed how you work. A story that suggests you never learned the basics can't.
- It has a “since”. You can name a time you've used what changed.
Good places to look are a missed estimate, a launch that didn't do what you expected, a decision built on a wrong assumption, or news you passed on too late.
For the mistake wording, the safest examples are errors in how you worked, such as a skipped check or an unasked question, rather than a gap in a skill the job depends on.
How to tell it
A clear order helps the interviewer follow you, and most of the time should go to what happened after the failure.
What went wrong, including your part. Keep it to a sentence or two, and say your part plainly: “I promised Friday before checking with engineering,” not “a timeline issue came up.” Amazon's leadership principles describe the standard: leaders are “vocally self-critical, even when doing so is awkward or embarrassing.”
What you did straight away. How it came to light, who you told, when, and how you limited the damage. In a discussion of engineering behavioral interviews, a strong failure answer covers how, when and with whom you communicated, including your first estimate of the impact.
What you changed afterwards, and a time you've used it since. Spend most of your time here. A product interviewer asks how you applied the lesson to later work, and says the answer shows a lot about how candidates learn, think and operate.
It follows the same order as a STAR answer, with the change added at the end.
Example answers
In each made-up stronger answer, the candidate's own part comes within the first two sentences, so the same story works for a failure or a mistake question. Check how long yours takes to get there.
Software engineer
Weaker
“We missed the deadline on a big migration because the requirements kept changing and another team was late with their API. I stayed late a lot to catch up, and we got it done in the end. I learned how important communication is.”
Other people caused the failure, the fix was working longer hours, and the lesson doesn't change anything.
Stronger
“I shipped a change to our checkout service that I'd only tested with small baskets. It passed review, but in production, orders with more than 50 items started timing out.
I saw the alerts within about ten minutes, rolled the change back and posted in the incident channel. I said what I'd changed and that around 300 orders were affected. Support contacted those customers that afternoon.
I'd assumed our test data looked like real traffic. Now any change on a busy path gets a test with production-sized data, and that's on our review checklist. Last month it caught a similar problem in a teammate's change before it shipped.”
The candidate's part is clear from the first sentence, the repair includes who was told and how much was affected, and the change has been used since.
Product manager
Weaker
“My biggest failure was a feature that didn't get the adoption we hoped for. Looking back, the market just wasn't ready for it. It taught me that timing is everything in product.”
The market gets the blame. There's no decision of the candidate's to discuss, so the interviewer learns nothing about their judgment.
Stronger
“I pushed to build a bulk-editing feature because three of our largest customers asked for it. I didn't check how many other customers had the same problem.
After launch, those three used it and almost nobody else did. It took two engineers most of a quarter.
When the numbers came in after a month, I told my manager and the team that I'd given a few loud accounts too much weight. We kept the feature for those customers, stopped further work on it, and moved the engineers back to onboarding, our bigger problem.
Now, before I commit a team to a request, I check how many accounts have the problem, not just who's asking. Last month that led us to turn down a reporting request.”
A failed bet with a clear mistake inside it, a decision to stop rather than keep investing, and a check the candidate still uses.
Product designer
Weaker
“I designed a new navigation that tested really well, but engineering didn't have time to build it properly, so the final version was a mess. It taught me to push harder for design quality.”
Engineering is blamed, and “push harder” sounds like the candidate would repeat the same conflict next time.
Stronger
“I redesigned the settings screens in our mobile app and tested the prototype with five people, who all found everything easily. None of them used a screen reader, and I hadn't thought to include anyone who did.
After launch, support had complaints that the new toggles couldn't be reached with VoiceOver. That week I worked with an engineer to fix the labels and focus order, then wrote to the people who'd complained once the fix shipped.
Now every usability round I run includes at least one participant who uses assistive technology, and our design review has an accessibility step. It has caught problems on two projects since.”
The gap in the candidate's own research is named early, the repair reached the affected users, and the change is now part of how the team works.
Data analyst
Weaker
“Once I made a small typo in a SQL query, but I caught it before anyone saw the results. I've been extra careful ever since.”
Too small to be a real answer. Interviewers tend to read a slip like this as avoiding the question.
Stronger
“I reported that a pricing change had raised conversion by 8%. Two weeks later I found I'd included internal test accounts, which made the new price look better than it was. The real figure was closer to 2%.
I told my manager the same day, then sent everyone who'd seen the original a correction with the new numbers and what had gone wrong. The pricing decision stood, but the team lowered its revenue forecast.
Now test accounts are filtered in one shared view rather than in each query, and every result I send says what's been excluded. A colleague used that view for her own analysis last week.”
An error in the analyst's main skill, which works here because it was corrected quickly and openly and the fix protects other people's work too.
Program manager
Weaker
“A program I ran was three months late because the vendor kept missing their dates. There wasn't much I could do about it, but I kept everyone informed.”
The vendor is the cause, and “there wasn't much I could do” leaves nothing for the interviewer to assess.
Stronger
“I ran our support team's move to a new ticketing system, and we went live two weeks late. The cause was mine: I planned around the vendor's standard setup time and never asked whether our custom fields would add work. They did.
When the vendor raised it, I told the support leads that afternoon, with a new date and what the delay would cost them. We kept the old system running for the extra two weeks.
Now my plans include a step where I ask each vendor what would make our setup take longer than usual, and I write the answer into the plan. On the next rollout, that question brought a security review to light early, and we planned around it.”
It owns the assumption behind the delay, shows how the people affected were kept informed, and the new step has already paid off once.
Consultant
Weaker
“On one project the client didn't follow our recommendation, and the savings never happened. I learned that clients don't always listen, so you have to communicate really clearly.”
The client failed, not the candidate, and the lesson is too vague to picture.
Stronger
“On a cost project for a manufacturer, I built the savings model and presented it to the client's operations director. I'd used head-office data and never checked it with the plant managers.
In the meeting, one of them pointed out that two plants had already made those cuts, and the director lost confidence in the whole model.
That evening I called the plant managers, rebuilt the numbers with them, and sent a corrected version two days later. The savings came out about a third smaller.
We kept the project, but it took weeks to win back the director's trust. Now I check the main numbers with the people who run the operation before anything goes to a senior client.”
It's honest that part of the damage wasn't undone, and the habit it led to is specific enough for the interviewer to picture.
How a mistake answer differs from a failure answer
The two wordings overlap, but they point at different things. Knowing which one you've been asked tells you what to lead with.
A failure is an outcome that fell short: a missed goal, a launch nobody used, a cancelled project. You can fail without a clear error, for example when a reasonable bet doesn't pay off. A product interviewer on Reddit asks about an idea that didn't perform, because good product managers should be testing ideas regularly.
A mistake is something you did wrong: a decision, an error, a step you skipped. The interviewer wants you to name it.
A product leader who screens candidates uses the mistake question to check whether candidates readily admit mistakes. Answers like “I hired someone who turned out to be a dud” are instant rejections, because they blame someone else.
A mistake answer is judged on three things: who spotted it, whether you owned up, and whether you made that kind of error less likely, as one reply on r/interviews breaks it down. The last part means a check or a change to how the work is done: “I'm more careful now” doesn't answer it.
Most real stories work for both, since a failure usually has a mistake inside it. Use this table to adjust the same story to the wording you're given.
| Failure question | Mistake question | |
|---|---|---|
| What it's about | An outcome that fell short | Something you did wrong |
| Lead with | The goal, and what happened | The error, and your part in it |
| Spend the most time on | What you'd now weigh differently | The repair, and what stops it happening again |
| Watch out for | Blaming circumstances | Choosing a slip too small to matter |
One caution with failure stories: “it was a reasonable bet” is true of many failures, but it can also be a way of avoiding your part. If there was a decision you'd make differently now, say so.
When the outcome was never fixed
Some failures don't have a recovery. The customer left, the project was cancelled, or you moved on before it was resolved. You can still use them, and they often sound more believable than a story with a neat ending.
Say plainly that it wasn't fixed. Then put the weight on what you did at the time to limit the damage, and on what you've done differently since. As Why behavioral interviews feel so hard puts it, you don't need to manufacture a happy ending.
If you haven't had the chance to use the change yet, say what you'd do and be honest that it hasn't been tested. The interviewer may ask, and an honest “not yet” is better than a made-up second story.
What makes the answer go wrong
Most weak answers protect the candidate instead of answering the question. These are the common versions:
- No example at all. An interviewer in a product management thread treats having no answer to this question as an automatic no.
- Someone else's failure. The team, the vendor or the client caused it, and you were the one who noticed.
- A success in disguise. “We hit the deadline, but I worked too many late nights” doesn't answer the question.
- Too long on the failure itself. Detail about what went wrong crowds out the parts they're listening for.
Other ways it gets asked
The question comes in several wordings, and the same story usually works with a small change in emphasis.
“What's your biggest failure?” or “your biggest mistake?” Choose something that mattered, but the same check applies: it shouldn't suggest you can't do the job.
“Tell me about a time you were wrong.” Closest to the mistake wording, often about a judgment or an opinion you changed.
“Tell me about something you launched that didn't work as you expected.” Common for product managers and designers. It's a failure question, so explain why the decision seemed right and what you'd weigh differently now.
“Tell me about a setback.” Broader. A setback can be outside your control, but the strongest answers still include a decision of yours.
Like the weaknesses question, this one tests whether you notice your own patterns and change them. Use a different story for each question. The software engineer and consulting guides cover what interviewers in those fields listen for, and what a behavioral interview is explains how this question fits with the others.