So tell me about a time you failed.
That sentence, said quietly across a video call by an interviewer with one eye on a checklist, is the question I have watched go wrong more often than any other behavioral question. The candidate I am thinking of, on a mock from last quarter, paused for a long moment, smiled tightly, and said:
"Honestly, I cannot think of a real failure. I work hard not to fail."
We ended the mock there. I told her the answer she had just given would have been disqualifying at any senior loop I had ever interviewed for. Not because she was a bad engineer (she was not). Because the answer signaled that she had not done the work to prepare for what is, in my experience, the most reliable single signal in a behavioral round: how candidates talk about their own failures.
This article is the prep work I do for the failure question and the prep work I tell candidates to do. It is more involved than most people think, and it is the highest-ROI hour of behavioral prep I know of.
What the question is grading
The failure question is grading self-awareness, almost exclusively. It is not grading whether you have failed (everyone has). It is not grading the magnitude of the failure (small failures often score better than large ones). It is not even mostly grading what you learned (although that is the visible artifact).
What it is grading is whether you can, on your own, identify a real failure, describe it without performing humility or deflecting blame, and articulate what you learned from it in a way that suggests the lesson actually changed your behavior. Self-awareness is the variable.
If you cannot articulate a failure on demand in an interview, the interviewer's prior is that you cannot articulate one to your manager either, which means you are likely the kind of engineer who needs feedback delivered explicitly because you do not surface your own gaps. That is a leveling concern, especially at senior and above, where self-driven calibration is part of the job.
This is why "I cannot think of a failure" is disqualifying. It is not what the candidate intends to communicate, but it is what the interviewer hears.
The prep work that nobody does
The right prep is to write down five real failures from your career. Real ones. Not failures-in-the-shape-of-strengths ("I cared too much", "I worked too hard"), and not failures that are technical mistakes you immediately fixed. Real failures: things you did, or did not do, that had a downside outcome you can articulate, where the cause traces back to a decision or a habit of yours.
The first one is the hardest to write. The fifth one is suddenly easy. The reason is that the act of writing one real failure unlocks your memory of others; once you have admitted to yourself one specific time you did not do well, the cognitive blocker on remembering the others lifts. Most candidates I mock with cannot get past one when I ask them to do this exercise on the spot. The candidates who have done the writing exercise in advance can usually tell me four or five.
The five-on-paper exercise is not because you will tell five failures in the interview. It is so that the failure you do tell is the third most painful one, not the most painful one. The most painful one is too raw and you will deliver it with edges. The fifth most painful is too small and the interviewer will read it as evasion. The third one tends to be calibrated correctly: significant enough to count, far enough back that you can talk about it cleanly, and clearly attributable to your own choices.
The shape of the answer
The load-bearing section is 3 ("with you as the cause"). Most candidates skip this section and go straight from 2 to 4. The interviewer hears the gap. "It went wrong, and then I learned X" is not a failure story; it is an event that happened to the candidate. "It went wrong because I had not invested in understanding the deployment pipeline, and I should have, and that was on me" is a failure story. The difference is in the explicit assignment of cause to your own decisions.
This is the section that makes candidates flinch. The section requires you to say, out loud, in a high-stakes setting, that you were the reason something went wrong. People avoid doing this because it feels like volunteering a weakness. The reframe that helps me is that you are not volunteering a weakness; you are demonstrating self-awareness. The interviewer is not going to use the failure against you (they cannot; they barely know you). They are going to use the quality of your reflection on the failure as a signal of how you would behave on their team. The reflection is high-leverage. The actual failure is not.
Three failure shapes that work
From the failures I have heard candidates tell well, three shapes recur:
The over-confident decision. A specific moment where you committed to an approach without enough data, the approach failed, and you can describe the data you should have gathered. The version that lands well includes the moment of false confidence ("I had built something similar before, so I assumed...") and the moment of correction ("I should have run a smaller spike first, and now I always do for systems I have not personally operated"). Concrete, specific, and the lesson is observable in your subsequent work.
The skipped maintenance. A piece of work you put off (refactoring, documentation, monitoring, dependency upgrades) that came back to bite you in a way that was attributable to the procrastination. The version that lands includes the rationalization at the time ("the team was busy and the existing code was working") and the cost when the chickens came home ("the outage cost us six hours of customer-facing impact and traced cleanly back to the deferred upgrade"). The lesson tends to be process-shaped ("we now batch deferred maintenance into the first week of every quarter"), which signals that the lesson became operational, not just emotional.
The interpersonal misread. A moment where you handled a colleague poorly because you misread the situation. The candidate I have heard tell this best described shutting down a junior engineer's pushback during a code review, getting feedback later from her manager that the junior engineer had been right and felt steamrolled, and changing how she handled disagreement in code review afterward. This shape works because it requires both technical and interpersonal self-awareness, and the change is observable in subsequent behavior.
What does not work, in my experience, is the failure-of-circumstance: "the project failed because the company pivoted". The interviewer cannot grade your self-awareness on a story where you were not the cause.
The three things to avoid
The failure-shaped strength. "I sometimes care too much about quality and ship slower than I should." The interviewer has heard this exact sentence forty times. They will recognize it for what it is and score the round down for evasiveness. Do not do this.
The blame-distributed failure. "The team had communication issues and we missed the deadline." The interviewer cannot tell what your role in the failure was, and the answer signals that you cannot tell either. If your contribution to the failure was small, pick a different failure where it was large.
The ancient failure. "In my second year of college, I procrastinated on a project." The interviewer is grading you as a working engineer; a college failure does not show how you work now. Pick something from your professional career, ideally within the last three to four years, recent enough to remember in detail but old enough to have observable downstream lessons.
The conversation I had with my mentor about my own version
The failure I told in my last loop was about a deployment I owned that broke production for two hours. The first time I drafted the story, I had spent most of the time on the mitigation (we rolled back, we wrote a post-mortem, we improved the canary, we did better afterward). My mentor read the draft and pushed back: "Your draft has a paragraph and a half on what went wrong, and four paragraphs on how the team recovered. The interviewer is grading you, not the team's recovery process."
The rewrite weighted toward what I specifically had not done in advance. I had not run a load test on a configuration change that I had assumed would be benign. The reason I had not run the load test was that I had been on-call and tired, and had taken a shortcut on the change-management checklist that I knew I was supposed to follow. I rationalized the shortcut because the change "looked like" similar changes I had made before, but the configuration was actually subtly different, and I had not paid attention to the subtlety because I was tired.
The rewritten story spent thirty seconds on the rollback (cleanly, but briefly), and ninety seconds on the specific decision I had made under fatigue and the change-management discipline I now follow on tired days, including a personal rule I adopted (no production changes after 7pm without a co-reviewer, regardless of how routine the change appears). The interviewer in the loop nodded twice during the lesson part. I got the offer.
What the answer is really doing
The failure question is, in my experience, the question where the gap between prepared candidates and unprepared candidates is widest, and where the prep is highest leverage relative to the time it takes. An hour of writing five real failures, picking the third, drafting the answer in the shape above, and rehearsing it twice will give you a version of the answer that scores well in any loop you walk into.
Most candidates will not do that hour, because the work is uncomfortable. The candidates who do are the ones I have watched walk out with offers. The interview is not going to remember the facts of your failure a week later. It will remember whether you sounded like the kind of engineer who can see themselves clearly. That is the variable.