Tell Me About a Time You Failed: How Software Engineers Should Answer

Nobody enjoys this question. You’ve spent the whole interview showing your best work, and now you’re asked for your worst.

Interviewers want to know what you’ll do when something goes wrong on their team. They listen for whether you own your part, how you responded, and whether you work differently now. A modest failure that changed how you work gives you more to talk about than a disaster you learned nothing from.

Pick the right failure

Pick a real mistake with a consequence: someone lost time, a date slipped or something went down. Choose one where you made the call or missed the warning, and can explain how you helped put things right. You should also be able to point to something you changed afterwards.

For engineers, these usually work:

Don’t use “I worked too hard” or “I care too much about quality.” Interviewers have heard both many times, and neither is a failure. Don’t pick a story that is mostly about what a teammate or a manager did wrong. Skip anything where you hid a mistake.

Tell it in four parts

Set the scene in two sentences: the project and your role. Then say plainly what went wrong and what your part in it was. Spend most of your time on the last two parts, which are what you did about it and what you changed afterwards. If you can, end with a later moment when the change paid off.

That’s about two minutes in total. The usual way to waste them is to spend the first ninety seconds on background.

Two sample answers

An outage you caused

“Two years ago I ran a database migration on our orders service. I’d tested it on staging, where the table had a few thousand rows, and it finished in seconds. Production had 80 million. The migration locked the table for eleven minutes in the middle of the business day, and checkout was down the whole time.

That one was on me. I never tested against production-sized data, and I had no way to stop the migration once it started. I posted in the incident channel straight away, worked with our database engineer to let it finish safely, and wrote up the incident that afternoon.

Now I test every migration against a copy of production data, and I write the rollback steps before I run anything. I also added a check to our deploy pipeline that flags migrations on large tables. It’s caught three from other engineers since.”

A missed deadline

“Last year I led the work to add single sign-on to our product. I estimated six weeks and it took eleven. A customer who was waiting on it had to push back their own rollout.

My estimate only covered the main login flow. I hadn’t looked at how existing accounts would be linked to the new logins, and that turned out to be half the work. I also didn’t tell my manager we were behind until week five, because I thought I could catch up.

Once I raised it, we cut two smaller features and gave the customer a new date, which we hit. These days I spend the first few days of a project listing the parts I haven’t looked into yet, and I report against the estimate every week. On my next project I flagged a risk in week two, and we changed the scope before the date moved.”

Be specific about your part in the mistake. “We missed the deadline” leaves the interviewer wondering what you were responsible for.

Expect follow-up questions

Interviewers rarely stop at the first answer. These are the usual ones:

Think through these details while you prepare, especially if the project was a while ago. Stick to what happened; an inflated story gets hard to explain once someone asks about the details.

One story, several questions

The same story, told with a different emphasis, also answers “Tell me about a mistake you made,” “Tell me about a time you got critical feedback” and “Tell me about a project that didn’t go as planned.” It can cover “What’s your biggest weakness?” too, if you start from the habit behind the failure and what you do about it now.

Have a second failure story ready. Some interviewers ask for another one.