How do you answer tell me about a failure without looking incompetent

Pick a failure where the damage was real but the recovery is yours to describe. The interviewer is not scoring the size of the mistake, they are scoring whether you can name your own decision and say what you changed. A small, specific, clearly-owned failure beats a large one you blame on circumstances.

Should I describe a time I failed at a job interview or can I use a personal example

Use work if you have any work history at all. Personal examples cost you the thing the question is testing, which is judgment under professional stakes with other people's money or time involved. If you have no work history, use a project with a real deadline and real collaborators.

What follow-up questions come after this one

The one that breaks most answers is which part was your call rather than the team's. After that comes what you changed afterwards, phrased so a former colleague could confirm it. Prepare a specific decision and a specific behaviour change and both follow-ups land somewhere.

Tell Me About a Time You Failed (Answer Examples)

Why interviewers ask this

When an interviewer says tell me about a time you failed, they are checking whether you can describe a decision that went wrong while it is still attached to you, in the first person, without handing it to a team. The second thing they measure is whether the failure was real. Real means it cost money or time that somebody else had to account for, rather than a tidy setback you recovered from inside a week and now present as growth. Most candidates asked to describe a time you failed arrive with a story that has been sanded down over several tellings until the only people who look bad in it are a vendor or a manager who has since left the company. Any interviewer who has run a few hundred of these rounds hears the sanding in the first fifteen seconds, and the rest of the conversation becomes an attempt to find out what actually happened.

An answer that sounds fine

I was leading the migration of our billing system to a new provider, and we committed to a go-live at the end of Q3. About three weeks out, we found that the historical invoice data wasn't mapping cleanly to the new schema. I raised it with my manager straight away and we pulled in two more engineers to work through the exceptions, but we still missed the date by roughly six weeks and had to run both systems in parallel over the holidays. Looking back, we underestimated how messy fifteen years of legacy data was going to be. I learned a lot about validating assumptions early, and now I build a proper data audit into the first phase of every migration I run. It made me a stronger lead.

Where it breaks

Every verb that matters in that story belongs to a group. We found the mapping problem, we pulled in the engineers, we underestimated the legacy data. The only first-person verbs in the whole account are I raised and I learned, and raising something is what you do at the point where the problem has already become someone else's to solve. The single number in the story, six weeks, is attached to the slip rather than to the decision that produced it, so nothing in the account gives a listener anything to push on, and there is no moment where the candidate stood at a fork. The story has been assembled so that nobody in it ever made a call that turned out to be wrong. That is the standard shape of every rehearsed answer to an interview question about failure, and it is the precise reason the next question exists.

The follow-up

Which part of that was your call, and not the team's?

So, I mean, I was the lead, so it lands on me in the end. I think the piece that was mine was, we had a data audit scheduled for week two and I pushed it to week five because the provider integration was slipping and I needed the engineers on that. Or week four. I'd have to go back and check. That's the one I'd take back.

That is the first true sentence in the conversation, and it took a second question to get to it. The decision was available the whole time, sitting underneath a plural pronoun, and pushing the audit is the only moment in the story where the candidate stood between two options and picked the wrong one. Everything after this runs on that admission, because the interviewer now has a concrete call to examine, made on a specific week, instead of a schedule that appears to have slipped on its own.

An answer that holds up

I was leading a billing migration with a go-live at the end of Q3. In week two I had a data audit on the schedule and I pushed it back three weeks, because the provider integration was behind and I decided the audit could wait. That was my call, and I made it without talking to the two engineers who knew the legacy schema best. When we ran the audit in week five, about forty percent of historical invoices didn't map, and we shipped six weeks late with both systems running in parallel. My manager heard about the slip from the vendor before she heard it from me, and that is the part I would undo first. Since then the data audit goes before anything else on a migration, and I tell my manager the day a date starts moving instead of the week I have a fix ready to present alongside it.

The interviewer asks the same thing, which part was his call and not the team's.

Pushing the audit. I had enough information in week one to know it was the risky trade and I made it anyway, for a deadline I went on to miss regardless. The engineers had flagged the schema inconsistencies and I heard it as a scheduling problem rather than a data problem.

Someone asked to give an example of a time you failed gets that same second question whatever story they bring, so the repaired version puts the audit decision in front of it and lets the follow-up land on something solid.

Practice this question

Say your answer to this question out loud, then get asked which part was your call. Answer it now, free, no account.

Tell Me About a Time You Failed