Failure and Mistake Questions

Failure questions test whether you own a real mistake, limit the damage and change how you work, so pick a true failure, not a strength in disguise.

How It Works

"Tell me about a time you failed" sounds like a trap, but it's one of the more generous questions in the round. Everyone has failed at something. The interviewer wants to see how you handle it: whether you can name your own part without blaming anyone, what you did once you noticed, and whether you work differently now. Self-awareness is what's being scored, and it's hard to fake.

Pick a real failure with a real cost: a missed deadline, a bug that reached customers, a project you pushed for that didn't pay off, an estimate that was badly wrong. It should be yours, at least in part. Skip the humblebrag. "I work too hard" and "I care too much about quality" are strengths in disguise, and interviewers hear them as dodging the question.

Get the size right. The story should be recent enough that the lesson still shapes how you work, and meaningful enough that it cost something. But it shouldn't be so catastrophic for the company that it overshadows everything you say after it.

What happened. One or two sentences of situation.
Your part in it. Say plainly what you did or didn't do. "I", not "we" or "the process".
How you limited the damage. What you did in the first hours and days once you noticed.
What changed. The habit, check or practice you use now, and ideally a time since when it helped.

Keep the failure short and give most of your time to the last two steps. The interviewer remembers how the story ends, and you want it to end on what you did about it. Use STAR as usual, with the reflection carrying more weight than it does in other answers.

Expectations scale with level. A junior engineer's failure is often a bug or a missed estimate, and the lesson can be a personal habit. Senior candidates should own failures of judgment, like a design that didn't hold up, a project they should have stopped sooner, or a risk they saw and didn't raise. Their lesson should reach past themselves, into how the team plans, reviews or ships.

What Interviewers Listen For

A real failure with a real cost, not a strength in disguise.
Ownership: your part, said plainly, with no blame passed to others.
What you did to limit the damage once you noticed.
What changed in how you work, and evidence that the change stuck.

How It's Asked

The same question comes in many wordings. Any of these wants the same kind of story.

Tell me about a time you failed.
What's the biggest mistake you've made at work?
Tell me about a project that didn't go the way you planned.
Tell me about a time you missed a deadline.
Describe a decision you'd make differently if you could go back.
Tell me about a bug or outage you caused.
Tell me about a decision you got wrong.

Sample Answers

The Question

Tell me about a time you failed.

Try drafting your own answer first, then compare. Both answers are invented.

Show Sample Answers

A Common Answer

Honestly, I'd say my biggest failure is that I take on too much. On one project I said yes to a lot of extra tickets because I wanted to help the team, and I ended up working late most nights to get everything done. We still hit the deadline, but I learned that I need to say no sometimes and protect my time.

A Strong Answer

At a consumer lending startup I owned the job that emails customers a reminder three days before a loan payment is due. I rewrote it to run per region instead of in one big nightly batch. The rewrite was my idea and my code. I tested it carefully, but only in my own time zone.

When it shipped, about 3,000 customers in our two westernmost time zones got their reminder a day late. Most still paid on time, but 41 paid late and were charged a late fee. I found out the next morning from a support ticket that mentioned the reminder date. Within twenty minutes the logs showed it was my change, and I told my manager before anyone asked: this is mine, here's what I know, here's what I'm doing.

Then I worked on limiting the damage. I rolled the job back to the old batch version that morning so the next day's reminders went out correctly. I wrote a query to find every customer whose reminder was late, and worked with our support lead to waive all 41 late fees and send those customers an apology that week. I also wrote the incident review myself, and I said plainly in it that I'd only tested one time zone.

What changed is how I test anything with dates. Our CI now runs the scheduling tests in four time zones and across a daylight saving change, and I added a question to our pull request template about what happens at midnight and at month end. New batch jobs also go to 1 percent of customers first. Six months later, those multi-zone tests caught a daylight saving bug in a teammate's change before it shipped. The bigger lesson for me was that "I tested it" only covers the cases I thought of. Now I ask someone else to list cases before I write the tests.

Why It Works

The weak answer is a strength in disguise. Taking on extra work and still hitting the deadline cost nothing, so there's nothing to own and nothing to learn.
The strong answer names the candidate's part right away ("my idea and my code") and tells the manager before anyone asks. That's the ownership interviewers are listening for.
Most of the strong answer is about what came after the mistake: the rollback, the waived fees, the incident review, and the tests.
The lesson is specific and comes with proof it stuck, a test that caught a later bug. "I learned to be more careful" can't be checked.

Common Pitfalls

Giving a humblebrag. "I'm a perfectionist" tells the interviewer you won't name a real failure.
Blaming someone else, or the process. Even if others contributed, the question is about your part.
Picking something so old or so small that it costs nothing to admit, like a typo in a slide deck.
Spending most of the answer on the disaster. Keep the failure short and give the time to the recovery and what changed.
Ending with a vague lesson. "I learned to communicate better" sounds rehearsed unless you say what you now do differently.