Choosing and Tailoring a Story

Two skills, and both are practised rather than innate.

Choosing. Behavioural questions are a thin surface over a small number of signals. "Tell me about a time you disagreed with your manager", "a time you had to deliver bad news", and "a time you were the only person who thought something was a bad idea" are all conflict prompts, and your one strong conflict story serves all three with a different opening sentence. So the first move on hearing a question is not recall — it's classification. Which signal is this, and which of my tagged stories fits it best?

Then check three filters. Is it recent enough to be relevant — a story from six years ago implies nothing has happened since. Is it at the right scope for the level you're interviewing for — a story about a two-day bug fix answers a mid-level question. And is it fresh in your own head enough to survive four follow-ups, because the interviewer will keep pulling until something gives.

If nothing fits well, say so and adapt: "I don't have a clean example of that, the closest is —" is a perfectly strong answer, and much better than forcing a story that doesn't answer the question. Interviewers notice the mismatch; they rarely notice honesty as a weakness.

Tailoring. The same migration story is told three ways. For a hiring manager: the business risk, the sequencing, who you kept informed. For a peer engineer: the actual mechanism, the failure mode you were most worried about, the trade-off. For a founder: why it mattered to the product and what it unlocked. Same facts, different altitude. Get this wrong and a good story lands badly — mechanism detail to a founder reads as an inability to see the point.

One tailoring rule specific to this search: where a story touches the company's own domain — models, agents, developer tools, whatever they build — pull that thread forward. It's the same story, but now it's evidence you'd be effective in their codebase.

Most candidates prepare stories and then deploy them badly: the right material, the wrong question, or told at the wrong altitude for the person listening. Classification and altitude are the two adjustments that turn a prepared bank into good answers.

• Classify the signal first; the literal wording of behavioural questions is highly variable and mostly noise.
• One strong story per signal covers many phrasings — you're picking a category, not a project.
• Filter for recency, scope appropriate to the level, and how well you still remember the detail.
• Saying "the closest thing I have is —" beats forcing a story that doesn't answer the question.
• Adjust altitude by audience: business risk for managers, mechanism for engineers, product impact for founders.
• Foreground the parts of a story that touch the company's own problem space.
• Expect follow-ups to go three or four levels deep; pick stories whose depth you can actually still supply.