Building Your Story Bank

The mistake people make preparing for behavioral interviews is trying to prepare an answer for every question. There are hundreds of phrasings, so they either give up or memorise scripts that sound memorised. The better approach is the reverse: prepare a small number of strong stories, then learn which questions each story answers.

A story bank of about eight stories covers almost everything you will be asked. This post is about finding those stories in your own work, writing each one down so it is ready to use, and mapping them to the question families from the introduction. It ends with a real story bank built from the projects behind this site, which the rest of the track draws on.

What makes a story worth banking

Not every piece of work makes a good story. The ones that do share four properties:

You were the one acting. Not “I was on the team that…” but “I noticed, I decided, I built”. If you cannot describe your own actions for a full minute, it is not your story.
Something was at stake. A risk, a cost, a deadline, a disagreement. A story where everything went smoothly demonstrates nothing, because nothing tested you.
There was a choice. The richest stories have a moment where you could have gone two ways and chose one for a reason you can explain. That moment is what judgement questions are looking for.
It has an ending you can state. It shipped, or it failed, or it was cancelled, and you know what happened next. A story that is still in progress is hard to tell with a result.

Recent is better than old. A story from the last two or three years is easier to remember in detail and says more about who you are now. Professional is better than personal, but a side project counts if it was real work with real stakes — and for someone early in their career, a well-told side project often beats a vague story about a large team.

Where to find them

Most people sit down to list their stories and come up with two. The stories are there; they are just not filed under “stories”. Look in these places instead:

LOOK IN                          YOU ARE LOOKING FOR
  your commit history / PRs       the large changes, and the ones with long review threads
  incident write-ups              anything that broke and what you did about it
  design docs, RFCs               decisions with alternatives and a reason
  old performance reviews         what other people said you did well
  your calendar, 12 months back   the weeks that were stressful, and why
  project READMEs / notes         decisions you wrote down, numbers you measured
  "I'm proud of / I regret"       the two lists you can write from memory in five minutes

The notes are the best source if you keep them. Every project on this site has a progress_report.md recording what was decided and why, and that habit turns out to be the best interview preparation there is: the facts are already written down, with the numbers, on the day they happened, rather than reconstructed from memory a year later.

Writing each story down

For each candidate story, fill in the same worksheet. Write it in notes, not prose; you are building the raw material, not the script. The script is what you must avoid — a memorised answer sounds memorised, and it breaks the moment the interviewer asks a question slightly different from the one you rehearsed.

STORY: ______________________________   (a short name you will remember)

SITUATION   2-3 sentences. Where, when, what was going on, why it mattered.
TASK        1 sentence. What YOU had to achieve.
ACTIONS     3-5 bullets. What you did, in order. For each: why that, not something else.
CHOICE      The moment you could have gone another way, and the reason you didn't.
RESULT      The outcome. A number if there is one; how you knew, if there isn't.
LEARNING    One sentence. What you would do differently, or now always do.
FACTS       Dates, sizes, counts, costs. CHECK THEM against your notes.
FOLLOW-UPS  The three questions you would ask if you were the interviewer.
FAMILIES    Which question families this story can answer.

The facts line is the one people skip, and it is the one that saves you. When you tell a story ten times from memory, the numbers drift: a two-week project becomes a month, three hundred users become a thousand. The interviewer will not catch it, but you will be defending a number you are no longer sure of, and that uncertainty is audible. Check every figure once against the record and then use exactly that figure.

The follow-ups line is the other one worth the effort. Interviewers dig, and the digging is where most of the scoring happens. If you have already asked yourself “what would you do differently?”, “how did you know it worked?” and “what did the others think?”, you will answer them calmly instead of improvising.

Mapping stories to questions

Once you have six to ten worksheets, build a grid: stories down the side, the question families across the top, and a mark wherever a story can answer that family well. Then check two things.

Every family has at least one mark, ideally two. A family with no story is the question that will catch you out, so it is where to look hardest for material — or, if you genuinely have no such story, where to prepare an honest answer about why.

No single story carries everything. The best story is tempting to use for every question, and in a loop of four interviewers comparing notes, telling the same story four times looks thin. Each interviewer is usually assigned different traits, so spread your strongest stories across them.

A real story bank

Here is the story bank this track is built from. Every story is a real project behind this site, recorded in its project notes, and each later post tells one of them in full:

STORY                                   PROUD  FAIL  DISAGR  AMBIG  OWNER  LEARN
  1 WordPress -> AWS migration            ##                  ##     #
  2 the "12 tutorials" stale-index bug           ##                  #
  3 72 MB of build artefacts pushed              ##                  #
  4 the rule that was wrong                             ##     #
  5 the forgotten public API                                         ##
  6 indexes that drifted silently                #                   ##
  7 rehearsing a MySQL 8.4 upgrade                             #            ##
  8 teaching at scale: this site           #                         #      #

## = the best story for that family     # = a good second choice

A note on the word “I” in these stories. They are solo projects, built with a coding assistant doing much of the implementation. In the answers, “I” means what the person telling them owned: the decisions, the requirements, and the verification. Telling them in the room, that is exactly what to say if asked, as the proudest-project post shows.

Three things are worth noticing about the bank itself, because they apply to anyone's.

The failures outnumber the triumphs. Three of the eight stories are about something that went wrong. That is not a weakness of the bank; it is a strength. Failure stories are the hardest to find and the most valuable to have, because nearly every loop asks for one and most candidates arrive with a disguised boast instead.

One story covers several families. The migration is the proudest-project answer, but it also contains the best trade-off story — two requirements that contradicted each other — and a moment of ownership. Telling it for a trade-off question means starting at a different point and spending the minute on a different part.

There is a gap, and it is visible. The disagreement column has only one story, and it is a disagreement with a rule, not with a person, because these are solo projects. An honest bank shows you where you are thin. For that family, the conflict post gives a skeleton rather than pretending a story exists, and anyone with the same gap should fill it from their team work before the interview, not during it.

Practising without memorising

The goal is to be able to tell each story naturally, at the right length, starting from any question in its families. Three ways to get there:

Say it out loud. Telling a story in your head is not practice; you skip the hard parts. Record yourself and listen back once. You will hear the long situation and the “we” immediately.
Time it. Two minutes for the first telling. If you run long, the cut almost always belongs in the situation.
Start from a different question each time. Tell the migration story as an answer to “proudest project”, then to “a decision with no clear answer”. The facts stay the same; the emphasis moves. That flexibility is what makes a bank of eight stories cover forty questions.

What to take from this

Prepare stories, not answers: about eight, each written as a worksheet of facts rather than a script.
Strong stories have you acting, something at stake, a choice, and an ending.
Check every fact once against your records, then use exactly that figure.
Map stories to question families, and look hardest where the map is empty.
Bank your failures. They are the stories you will be asked for most and have least of.

Next: tell me about a project you are proud of — story 1, told in full.