The Behavioral Story Bank, Built to Cover the Question Set

You have behavioral interviews coming up and you need a set of stories that answers whatever they ask, without memorizing a script for every possible question. This guide is for candidates preparing for behavioral rounds and take-home-adjacent competency interviews, at any level. It gives you a repeatable method to mine your own history into the fewest STAR stories that leave no competency uncovered, and a grid that proves it.

Most advice hands you a number and stops there. Four. Five to seven. Eight to twelve. Twenty-four for Amazon. None of those numbers tells you whether your particular set answers the questions you will actually face. A number counts stories; it does not count coverage. This guide replaces the number with a coverage grid: competencies down one axis, your stories across the top, so you build the fewest stories that leave no cell empty and can see your gaps before the interviewer finds them.

Why a coverage grid beats a story count

A story count measures the wrong thing. The right unit is coverage: does every competency you are likely to be asked about have at least two distinct stories behind it? Ten stories all tagged to leadership is a full shelf and an empty grid.

The reason the published numbers diverge so wildly is that they measure different stages of the same process. Sources that say five to eight and sources that say fifteen to twenty are not contradicting each other. One counts the stories you keep in active use; the other counts the raw material you mine to get there. The move is to "mine wide, use narrow": brain-dump a large pile, filter hard, and keep a small working set that you can reach for under pressure.

The grid makes both numbers visible at once. The wide pile lives in your notes; the narrow working set is what fills the cells. When a cell is empty, you know exactly which of the wide pile to go back and rescue.

A story count measures your shelf. A coverage grid measures whether the shelf answers the question.

There is a second reason coverage beats count. At Amazon you are evaluated on roughly four to six of the sixteen Leadership Principles across a loop, but you never know which. Preparing sixteen separate scripts is wasted motion; preparing six to ten real stories, each mapped to the two or three principles it can serve, hedges against not knowing. Two stories per row is the hedge.

How many stories, by source and stage

The convergence, once you separate mining from use, is tight: mine 15 to 20, write 8 to 12, use 5 to 7. The table below shows what each named source recommends, kept in its own stage so the ranges stop looking contradictory.

Read the columns, not the rows. Where a source only gives one number, it is almost always the active-use figure, the stories you rehearse and reach for. The mining figure is larger by design because filtering throws work away, and you want to throw away from a pile rather than run short.

A common floor is that five to eight well-structured STAR stories cover roughly 80 percent of behavioral questions. That floor is real, but 80 percent coverage means one question in five finds a thin or empty cell, and that question is where the loop turns. The grid is how you close the last 20 percent deliberately instead of hoping.

Which competencies become your grid rows

Your rows come from two sources combined: the target company's published taxonomy, plus three to five competencies you pull directly from the specific posting. Never rely on a stock list alone.

Company taxonomies give you the published, non-negotiable rows. The three worth knowing differ sharply in size.

Amazon publishes 16 Leadership Principles, and each interviewer in the loop is assigned two or three to assess, with a Bar Raiser - an out-of-team trained interviewer holding veto power over the hire - checking the bar across them. Google scores four named attributes: General Cognitive Ability, Role-Related Knowledge, Leadership, and Googleyness, the last of which gets its own 30 to 45 minute session. Generic taxonomies converge on six to eight buckets: leadership, teamwork, problem-solving, communication and conflict, adaptability, and time management.

Derive rows from the posting itself

The company taxonomy is not enough because the specific role weights specific competencies. The documented procedure is to dissect the job description first, identify the top three to five core competencies, and only then brainstorm experiences. Read for signal words: "must have," "required," "essential," and "you will be responsible for" typically mark the competencies you will definitely be assessed on. This is not a style preference. The Levashina review confirms that basing interview questions on a job analysis is one of the most critical components of a valid structured interview, so the interviewer is scoring against the posting whether you read it that way or not.

Tailoring rows to each posting by hand is the tedious part, and it is exactly the friction Refolk removes when it tailors your material to a specific job description and scores how well your history actually fits the role's stated competencies.

The build procedure, start to finish

Here is the full method in order, with what to do at each stage and what done looks like. Run it once per target role, or once per company if several roles share a taxonomy.

The tagging step is where the grid earns its name. Map one story to the multiple competencies it can honestly serve: a conflict story can answer communication, ownership, and prioritization; a debugging story can answer ambiguity, technical judgment, and pressure; a launch story can answer leadership, metrics, and cross-functional work. Write two or three question tags under each story. Then read the grid down each column of competencies and count distinct stories per row - not tags on one story, distinct stories.

Making each story survive a follow-up

An anchor story is specific, high-stakes, role-clear, and outcome-rich. Those four criteria are also the disqualifiers in reverse: a story that describes what "I always" do, carries no stakes, hides your individual action behind "we," or ends without a number is not a keeper. Cut it in the filter step rather than discovering its weakness live.

Two of those criteria carry most of the weight because they are where scripts die. The first is role clarity. "We" is fine, but your piece must be nameable in one sentence. The Bar Raiser drill and the standard second follow-up both aim at exactly this: what did you do. A team-attributed story reads strong and fails the moment someone asks it. The second is the metric. A vivid story with no Result reads complete and scores low, because the rubric has a cell for outcome and yours is empty.

The success-or-failure split matters here too. For accountability and failure rows, you need a genuine failure where you name your own contribution to the problem and what you changed afterward. This is the row candidates skip, and it is the row that most reliably has an empty cell.

Where this goes wrong

The story bank fails in a small number of repeatable ways. Each has a false positive - something that looks like coverage but is not - and a specific check.

Two of these deserve extra weight. The first is the failure gap, because the market makes it structural. In Refolk's index of professional profiles, "Conflict Resolution" appears among senior US professionals about 26 percent more often than "Stakeholder Management" (32,479 versus 25,791), which tracks a wider pattern: candidates commonly arrive with a stack of teamwork and conflict stories and a single real failure story, if that. The common cell over-supplies itself. The rare cell is where the grid earns its keep, so plan your sourcing toward it.

The second is length creep, which is not merely bad etiquette. Interviewers lose interest past two minutes, and because each question with follow-ups consumes three to five minutes inside a fixed 45 to 60 minute session, a four-minute monologue costs the interviewer a whole question of signal. Over-length is self-sabotage under a fixed budget.

The last quiet failure is the wrong grid: using a stock six-bucket list when the posting names different competencies. The fix is upstream, in step one - derive three to five rows from the posting's own language rather than importing a generic taxonomy and hoping it overlaps.

Rehearsing so the right story arrives in seconds

Rehearsal has two jobs: make delivery automatic, and make retrieval fast. The first needs volume - at least five spoken reps per story until you are no longer reading. The second needs randomness, because in a real loop the questions do not arrive grouped by competency.

Run mock sessions where a partner fires questions in random order with only 30 to 45 seconds between them, and asks one or two follow-ups per story. This simulates the two things that break scripts: the scramble to reach the right story, and the probe that asks what you personally did or would change. A grid built on real, role-clear stories is follow-up-proof in a way memorized scripts are not, but only rehearsal proves it under time.

Competency tags: [2 to 3 rows this story fills]
Situation (10%): [1 sentence of context]
Task (10%): [your specific objective]
Action (60%): [what you personally did, step by step, "I" not "we"]
Result (20%): [the outcome, with a number]
Failure/learning variant: [if this is an accountability row: what you'd change]
Follow-up I expect: [the "what did you personally do" probe, pre-answered]

Find people who have sat on the other side of the table and can run these probes for real. Refolk can surface them from public professional records - for example, ex-Amazon Bar Raisers or hiring managers now coaching, or engineering managers who wrote publicly about failed projects and can pressure-test your failure story.

Verify before you walk in

Before you call the bank done, run this checklist against the grid, not against your gut. A bank feels finished long before it is covered.

Keeping the bank current

A story bank is not a one-time artifact. Rebuild the rows every time you target a materially different role, because the posting-derived rows change even when the company taxonomy does not. The 8 to 12 written stories mostly carry over; the tagging and the gap-fill are what you redo.

Two maintenance habits keep it sharp. First, after every real interview, log which questions actually came and which cell each mapped to - over a few loops this tells you where your grid mispredicted the question set. Second, keep mining. When a new project ships or a hard quarter ends, capture it as a raw entry while the numbers are fresh, so the wide pile stays wide and your failure and accountability rows stop being the ones you scramble to fill the night before.

The point of the grid is that it turns preparation from a guess about quantity into a visible statement about coverage. You are not trying to have enough stories. You are trying to leave no cell empty, and to know it before the interviewer does.