Tell Me About a Time You Failed

“Tell me about a time you failed” is the question candidates dread most, and it is one of the easiest to answer well, because the bar most candidates set is so low. The typical answer is a disguised boast — “I care too much”, “I worked so hard on it that I burned out” — or a failure that was somebody else's fault. Both tell the interviewer that you either cannot see your own mistakes or will not admit them, and neither is someone they want on call.

A real failure, owned plainly, with a specific change you made afterwards, is rare enough to stand out. This post covers what the question is testing, how to choose the failure, two worked answers from bugs that actually shipped, and the related “biggest weakness” question.

What the question is testing

Not whether you have failed. Everyone has. The interviewer is scoring three things:

• Self-awareness — can you see your own part in it, without being prompted?
• Ownership — do you say “I” for the mistake as readily as you say it for the successes?
• Growth — did anything change afterwards? Not “I learned to be more careful”, which is a feeling, but a concrete change in how you or your system works.

The third one is where nearly all the points are, and it is the part most answers skip or compress into one vague sentence at the end.

Choosing the failure

A GOOD FAILURE STORY                        AVOID
  a real mistake, clearly yours               a strength in disguise
  real but contained consequences             a catastrophe that ended a project
  you noticed it, or responded well           a failure blamed on others
  a specific change came out of it            "I learned to be more careful"
  not in the core skill of the job            a lapse in the exact thing they hire for

The last row needs care. A failure in your core competence is fine if the change you made is strong, but do not lead with “I didn't understand how databases work” when applying for a database role. A failure of process, verification or assumption — the kind every experienced engineer has — is the sweet spot.

Worked answer 1: the bug that shipped because the file size didn't change

Situation. My tutorial site is built from a content database in S3: one file per post, plus small index files that hold things like the number of posts in each category. The build downloads those files and generates the pages.

Task. I'd just published a thirteenth tutorial in the Oracle series and deployed the site.

Action — what went wrong. The live page read “12 tutorials” above a list of thirteen. It wasn't a cache: the built page itself was wrong, because the index file on my machine still said 12 while S3 said 13. The download step used aws s3 sync, which skips a file that is the same size unless the local copy is older. Changing “12” to “13” doesn't change the file's length — it was 4101 bytes either way — and because S3 timestamps are UTC, my freshly downloaded local copy looked newer. So the one file that decides every category count was silently skipped.

The mistake was mine: I'd relied on a sync tool's default behaviour without checking what it compared, and I had no check that would notice the counts disagreeing.

Action — what I changed. Two things. I added --exact-timestamps to the sync, so it only skips on an exact match, and confirmed the old command left the file at 12 while the fixed one corrected it. Then I added a check to the build that cross-checks the index files against each other — every category count against the actual list of posts. And I proved the new check would have caught it by reverting the count to 12 and watching the build get rejected.

Result. The page was corrected on the next deploy, and the build has refused to ship inconsistent counts since.

Learning. Every URL still worked, so nothing I had would ever have flagged it. Since then, when something goes wrong I ask “what check would have caught this?” and add it before I call the fix done.

Why it works

The failure is real, small and specific: a wrong number on a live page, not a catastrophe. The candidate owns it in one sentence — “the mistake was mine” — and names exactly what the mistake was: trusting a default without checking it. No self-flagellation, no excuses.

Most of the answer is spent on the change, and there are two levels of it: the immediate fix (the flag) and the systemic one (a check that catches the whole class of problem). The proof step — reverting the count to show the check fails the bad build — is the detail that marks someone who verifies their own fixes, and interviewers notice it.

Worked answer 2: the commit that should never have been pushed

The second story is a different kind of failure — not a bug in the product, but a mistake in process, and one whose consequences cannot be fully undone. That makes it a strong answer to “tell me about a mistake you made” in its own right.

Situation. Early in the same migration, I was moving fast and committing often.

Action — what went wrong. I pushed two commits to GitHub that included node_modules — 176 files of browser-testing bundles — and about 72 MB of regenerable migration output and images that already lived in S3. The .gitignore entry arrived a commit later, and an ignore rule doesn't untrack files that are already in the repository, so they stayed.

Action — what I did. I removed all 1137 files from the index with git rm --cached, which keeps them on disk and leaves the history alone, and extended the .gitignore so it can't recur. What I deliberately did not do was rewrite the history to purge them. That needs a force-push, which is destructive and can't be taken back, and I wasn't willing to do that as a reflex to tidy up a mistake.

Result. Nothing new gets tracked, but the old files are still in the pushed history, so the repository is larger than it should be. That's the honest cost.

Learning. The ignore file goes in before the first commit, not after the first mistake. And when cleaning up, I separate what's reversible from what isn't, and don't let embarrassment push me into the irreversible one.

Why it works

It has a cost that remains, and says so. Many candidates feel a failure story must end with everything fixed; a story that admits a lasting consequence is more believable and shows maturity. It also contains a judgement call inside the failure: choosing not to force-push. That turns a story about carelessness into one about knowing when to stop, which is a quality every team wants.

A skeleton for your own

SITUATION   just enough to understand what broke (2-3 sentences)
WHAT WENT   the failure, concretely: what a user/colleague saw
  WRONG     the cause, at the level a smart outsider can follow
OWNERSHIP   ONE plain sentence: "the mistake was mine: I..."
WHAT I      the immediate fix
  CHANGED   the systemic fix: the check, process or habit that prevents the class
            how you proved the systemic fix works
RESULT      the outcome, including any cost that remains
LEARNING    the question you now ask / the thing you now always do

Spend at least half the answer below the ownership line. If your story is mostly “what went wrong”, it is a confession; if it is mostly “what I changed”, it is evidence of growth, and that is what is being scored.

“What is your biggest weakness?”

This is the failure question's cousin, and it fails for the same reason: candidates offer a strength in disguise. The answer that works has the same shape as a good failure story, compressed: a real weakness, a moment it cost you, and what you do about it now.

For example, drawn from the two stories above: “When I'm moving fast I trust tools' defaults without reading what they actually do — a sync tool, a git ignore rule. It has cost me a wrong number on a live page and a repository that's bigger than it should be. What I do now is treat any step that moves data as needing a check that would notice if it did the wrong thing, and I add the check before calling the work done.”

That is real, it is not disqualifying, it has evidence, and it ends with a behaviour rather than a promise.

What to take from this

• The question scores self-awareness, ownership and growth, and almost all the points are in growth.
• Pick a real, contained failure that was clearly yours. Never a strength in disguise.
• Own it in one plain sentence, then spend most of the answer on what you changed.
• The strongest change is systemic: a check or process that prevents the whole class of mistake, ideally one you proved works.
• It is fine, even good, to admit a cost that could not be undone.

Next: conflict, disagreement, and disagreeing with your manager.