The failure and conflict questions, and building your story bank

"Tell me about a time you failed" is where preparation most often goes wrong before a word is spoken, because the choice of story determines the score more than the telling does. The conflict question fails the same way.

This lesson covers both, because both are decided at selection rather than delivery. Then it pulls everything in the section together into the deliverable of the framework half of the course: a story bank of ten to fourteen tagged stories, with the gaps visible.

The failure question: what it is testing

Not whether you fail. Everyone fails. Three things:

1. Can you name a real one? A candidate who cannot has either no self-awareness or no willingness to be honest with an interviewer.
2. Was it yours? Did you own the decision that went wrong, or are you describing weather?
3. Did anything change? A failure with no subsequent behaviour change is a story about bad luck.

The selection criteria

A usable failure story meets four tests:

Three stories, scored

Story A. "I once pushed a change on a Friday afternoon that broke the build for about an hour."

Real, owned, and trivially small. The interviewer's write-up: "Chose a low-stakes failure; could not or would not identify a substantial one." This is the most common failure of the failure question — not dishonesty, but choosing something safe.

Story B. "The project failed because we were understaffed and the requirements changed four times."

External attribution. Covered as a red flag in Red flags that end loops.

Story C. "I made a bad call on the notification service. We needed to add SMS alongside email, and I argued for building an abstraction layer over both so we could add channels later. It took seven weeks. We added no further channels in the next two years, and the abstraction made the email path slower to change — two people told me later they had worked around it rather than through it. The direct cost was about five weeks of one engineer, and the indirect cost was that the team stopped trusting my estimates for a while. What I'd do differently: I was designing for a future I had assumed rather than one anyone had asked for. Now, when I propose something on the grounds that we will need it later, I go and ask who has actually asked for it — and if nobody has, I build the specific thing and wait."

Owned, consequential, specific, resolved, and it produced a rule. That is the shape.

The failure that is too big

There is an upper bound. A failure that involves a data breach you caused, a serious ethical lapse, or being managed out is legitimate honesty and a bad interview choice. You are not obliged to volunteer your worst professional moment; you are obliged to give a real one.

Aim for: cost a team weeks-to-months, was your call, and you can describe the repair.

The conflict question

The conflict question is the most commonly botched question in the round, and the one that most reliably separates candidates who have prepared from those who have practised.

Why it is botched so often

Three reasons, all structural:

People do not think of their disagreements as conflict. Asked for a conflict, they search for shouting and find none, so they offer something trivial. "We disagreed about whether to use tabs or spaces" is a real answer people give.

People select the story where they were right. It is the natural instinct and it is usually the weaker story, because it ends with the other person being wrong and nothing changing in you.

People sanitise it until nothing is at stake. "We had a small difference of opinion, we talked it through, and we found a middle ground." Nothing happened, so nothing scores.

What a good answer proves

An interviewer scoring this question is checking four things:

1. You engaged rather than avoided. Silence and going around someone are both negative.
2. You sought their reasoning. Can you state their position, at its strongest, in their terms?
3. You separated the person from the problem. No characterisation of them as difficult, junior, or wrong-headed.
4. Something resolved. A decision was made, and you can say what you did afterwards.

Point 2 is the discriminator. It is very hard to fake, because it requires that you actually listened at the time.

The sentence that does most of the work

Somewhere in a strong conflict answer, this sentence appears:

"Their argument, and it was a reasonable one, was that —"

Followed by an accurate, non-strawmanned statement of the other side. Interviewers notice its presence, and they notice its absence.

Compare:

Weak: "They didn't really understand the performance implications, so I had to explain why their approach wouldn't scale."

Strong: "Their argument, and it was reasonable, was that we had shipped nothing to users in seven weeks and a simple synchronous version would let us learn whether anyone wanted the feature at all. My concern was that at our write volume the synchronous version would fall over at about 300 requests a second, and we were already at 180. Both of those were true at the same time."

The second candidate has demonstrated they can hold two valid positions simultaneously. That is the observable behaviour behind "earns trust".

Scale of conflict

The question does not require a crisis. Useful sources, in rough order of how often they are overlooked:

• A design review where you and another engineer wanted different approaches
• Pushing back on a scope or deadline set by a product manager
• Telling a manager you disagreed with a prioritisation call
• A code review that went several rounds and became tense
• Two teams disagreeing about who owned a system
• A performance conversation, in either direction

Section 9 (Earning Trust and Dealing with Conflict) develops all of these, including the case where you lost.

Building the story bank

With the career questions and the two selection-heavy questions prepared, you can build the deliverable of the framework half. Ten to fourteen stories, tagged, covering the taxonomy, with the gaps visible.

Why ten to fourteen

Fewer than about ten and you will repeat a story across rounds — which is allowed, but a candidate who tells the same migration story to three interviewers produces one competency's worth of evidence for a whole loop.

More than about fourteen and you cannot keep them at the depth Surviving the follow-up drill requires. Depth beats breadth every time; a fifteenth shallow story is worse than nothing because you will reach for it.

The coverage matrix

Build this table. Rows are your stories; columns are the twelve underlying questions from the question taxonomy. Mark P where a story is your primary answer and S where it could serve as a secondary.

Questions 1–6

Questions 7–12

Notice three things. Every column has at least one P. No story is primary for more than two columns. Columns 1 and 2 are answered from your career, not from a story, which is why they carry only secondaries.

Reading the gaps

Run three checks:

Empty columns. A column with no P is a competency you cannot answer. Go back to Mapping yourself to the rubric and decide: look again, reframe, or go and get one.

Overloaded stories. A row with four P marks is a story you will lean on until it breaks. Interviewers in the same loop compare notes; hearing the same project from three angles reads as a thin career.

Level clustering. Mark each row mid / senior / staff using the scope, autonomy, influence triad. If you are interviewing for senior and eleven of twelve rows are mid-scoped, the matrix is telling you something the wording cannot fix.

The honest part

Some stories are weak material. Not badly told — weak. A story where you were handed a task, did it competently, and nothing was at risk cannot be rescued by better phrasing, and the hours spent polishing it are hours not spent finding a better one.

The test: read the row and ask what decision did I make that someone else might have made differently? If there is no answer, cut the row.