Skip to content

Free guide

Be interview ready.

One answer I have heard dozens of times, marked up line by line. Then the same answer, told properly. If you only have ten minutes before a loop, spend them here.

Download the PDF Free, and no signup.

The one idea

A behavioural interview is not a storytelling contest. It is an evidence-collection exercise, and the interviewer is filling in a form while you talk. Everything below follows from that. Your job is not to be liked. It is to hand them evidence they can write down and defend to other people in a room you are not in.

That is why two candidates with the same experience get different outcomes. One handed over evidence. The other handed over a narrative.

One answer, marked up

Tell me about a time you failed.
What it is really testing: Accountability and learning.

We had a project last year that slipped by about a quarter. There were a lot of dependencies on other teams that didn’t land when they said they would, and the requirements changed partway through, which didn’t help either. Looking back, we probably should have communicated the risk earlier. I definitely learned the importance of setting expectations with stakeholders up front.

Nothing in that is a lie. It still gives the interviewer nothing to write down.

  • “we had a project that slipped” Whose project? Who was accountable?
  • “dependencies that didn’t land” Other teams’ fault.
  • “the requirements changed” Product’s fault.
  • “we probably should have…” Hedged, collective, hypothetical.
  • “I learned the importance of…” A lesson with no behaviour change attached.

The same answer, told properly

A strong failure answer is not only about what failed. It shows ownership, recovery, and what changed afterwards.

Situation I led the migration of a document-processing service onto a new control plane. I estimated eight weeks. It took twenty-two, and it blocked two other teams’ roadmaps for a quarter.
Task The estimate was mine, and so was the method that produced it.
Action The mistake was specific: I scoped the work by reading the service’s code, and I never spoke to the teams calling it. Two of them depended on an undocumented endpoint I’d planned to delete. I found out in week nine, when their integration tests broke in staging. I stopped the migration, wrote down every caller, went and talked to all three teams, and re-planned from what they told me rather than from what the code implied.
Result Twenty-two weeks instead of eight — there’s no way to dress that up. What changed is the method: I now build a caller inventory before I estimate anything. On the next two migrations I did that first, and both landed within ten percent of estimate.

That is the whole method. Running it across a career takes an afternoon, and there is a workbook that walks you through it.

What a strong answer actually needs

Four things, every time.

  • It answers the question asked. Relevance beats impressiveness. A bigger story that addresses something else reads as not listening.
  • Your part is unambiguous. "I" on the decisions, "we" on the outcome. The pronoun was never the problem; hiding your contribution was.
  • The action is concrete. What you actually did, in order. Not what you believe in, not what the team generally does.
  • There is a result, with evidence. A number when you can defend where it came from. Otherwise something equally checkable: what was adopted, what got reversed, what stopped happening.

Note what is not on that list: being impressive, being likeable, or having a happy ending.

Depth, when the story has it

These make an answer markedly stronger where they genuinely apply. They are not requirements, and forcing them onto a story that never had a rejected alternative is obvious.

  • A named alternative you rejected and why. This is where judgment is visible, and it is what separates a decision story from a delivery story.
  • An artefact that existed afterwards a one-page doc, a load test, a caller inventory. Something that outlived the conversation.
  • The trade-off you accepted what you knowingly gave up. An answer with no cost in it sounds like it was never a real decision.
  • A learning you later applied and where. A lesson with no subsequent behaviour attached reads as something said to sound reflective.

The ground a loop covers

A five-interview loop samples six or seven of these nine areas. Most candidates have genuinely prepared for two, usually ownership and problem solving, because those are the comfortable ones.

  • Scope and impact The size of problem you have genuinely owned, and whether it matches the level you are interviewing for.
  • Ownership and execution Driving something to done rather than flagging it, and measuring whether it worked.
  • Judgment and decision-making Choosing under incomplete information, and telling reversible decisions from irreversible ones.
  • Ambiguity and adaptability Turning a vague problem into actionable pieces, and changing course on evidence.
  • Conflict and influence Disagreeing productively, and getting something from someone who did not want to give it.
  • Communication and collaboration Adapting the message to the audience, working well alongside people who do not report to you, and being believed when it matters.
  • Learning, failure and recovery Owning a mistake, recovering from it in the moment, and showing the behaviour that changed afterwards.
  • Leadership and developing others Influence without authority, and making the people around you better.
  • Customer and product thinking Connecting your work to the person who uses it and the reason it was funded.

Which story to reach for

You will not be asked the question you prepared. You will be asked something adjacent, and the work is picking the right story from the ones you have in about four seconds. In this order:

  • Does it contain what they asked for? Relevance before anything else. The most impressive story you own is a weak answer to a question it does not address, and interviewers notice you answering the question you wanted.
  • Is it the biggest one that does? Among the stories that genuinely fit, reach for the one with the most at stake. Not the most dramatic, the most consequential.
  • Have I already spent it? Once a story has been told in this loop its value drops, so reach for a fresh one when it is equally strong. Reuse your best story only when it is clearly the best evidence for the question. Interviewers compare notes, and needless repetition reads as a short career.

What to do this week

  1. Take your best story and check it against the four essentials above.
  2. Find one number you have been approximating. It is in an old dashboard or doc.
  3. Write your answer to “what was the other option, and why didn’t you take it?”

Stuck for stories? They are in your old self-reviews, your design docs and their comment threads, and the calendar from the worst quarter you remember. Or ask a former colleague what they remember you for. It is reliably not what you would guess.

If you would rather work through your own answers with me directly, coaching is here.