How do you prepare stories for a behavioural round without ending up sounding rehearsed?

Six experiences, not twenty answers

The instinct is to collect the questions and write an answer for each, which produces twenty paragraphs, most of which will never be used, all of which sound written. Invert it. Pick six to eight real episodes from the last three or four years and know each one properly. A behavioural round asks four or five questions, so six well-understood episodes are already more material than any single interview can consume, and the mapping from question to episode happens in the room rather than in advance. That is also what stops the delivery sounding recited: you are selecting and shaping under mild pressure, which is exactly what natural speech sounds like.

What makes an episode usable is that something was uncertain at the time. A project that went smoothly from a clear brief has no decision in it, so it answers nothing regardless of how impressive the outcome was. Look instead for the fortnight you argued about something, the release that went wrong, the piece of work nobody owned, the thing you were asked for that you thought was the wrong thing to build.

Check the grid, not the question list

Lay your episodes against the competencies a loop actually grades and look for the empty column, because that is the question you will be improvising.

Episode	Ownership	Conflict	Failure	Ambiguity	Influence
Driver-app crash investigation	strong	—	strong	—	weak
Route-planner rewrite	strong	strong	—	strong	—
Warehouse scanner rollout	—	strong	weak	—	strong
Deprecating the old tracking API	strong	—	—	strong	strong

Two things fall out of a grid like that. Empty columns tell you which episode to go looking for in your memory, or which unglamorous one to promote. Overloaded rows tell you where you are about to repeat yourself: an interviewer who hears the route-planner rewrite for the third time will say so, and having nothing else ready reads as a thin career rather than a strong project.

Depth is what preparation actually buys

The measurable difference between a prepared candidate and an unprepared one is not fluency in the first ninety seconds. It is what happens at the third follow-up. Interviewers dig in layers: what did you do, then why that rather than the alternative, then what did it cost you, then who disagreed and what did they say. A story assembled the night before survives layer one and sometimes layer two, and then produces "I don't remember the details", which retroactively weakens everything already said.

So for each episode write down the facts rather than the sentences: the fork and the road not taken, the two or three people involved and what each of them did, the figure before and the figure after and how it was measured, the week the decision was made, one thing you got wrong. Five or six recoverable facts regenerate different wording each time you speak, which is the opposite of a memorised paragraph, and they are what the deep follow-ups are asking for anyway.

Re-angling instead of retelling

One episode can honestly answer several different questions, provided you change what the story is about rather than reciting it and hoping the relevance is obvious. The mechanics are in the first sentence and the last: the opening names the aspect being asked about, and the close returns to it. The middle is the same events, weighted differently.

This is a pattern to adapt, not a passage to learn — the wording should be yours and the facts must be.

Asked about failure. "The one I come back to is a crash in our driver app in 2024. We shipped a background location change on a Thursday and by Friday morning about one in twelve drivers on Android 13 was seeing the app die when they came back to it after a delivery. I had written the change and I had tested it on two devices, both on newer Android, and I had decided not to bother with the older test rig because the change looked small. That decision was mine and it was the whole cause. We reverted inside a day, but three regional depots spent a morning phoning drivers, and I had to sit in on that. What changed afterwards is narrow and specific: anything touching background services now goes through the older device rig before review, and I wrote the rig into the checklist so it was not just me remembering. Six or seven releases have gone through that since."

Asked instead about ownership, the same fortnight opens differently — "nobody owned the crash reporting, so I picked it up" — and spends its middle on the triage, the depot phone calls you volunteered for, and the checklist that outlived you, with the bad decision reduced to one honest clause. Same facts, different subject.

When the inventory is genuinely thin

Early-career candidates often conclude they have nothing, which is usually a scoping error rather than a shortage. Coursework, a dissertation, an internship, an open-source contribution, a part-time job in retail or hospitality all contain real conflict, real ambiguity and real ownership, and interviewers hiring at entry level expect exactly this. A disagreement with a group project partner about scope, handled well, is better evidence than a vague industrial anecdote you were barely part of. What does not work is inflating: a story where you were one of six people who watched something happen collapses on the first "and what did you do?".

One practical constraint to settle before the interview rather than during it: decide what you can say. Absolute revenue figures, unreleased product plans, named customers and security incident details are frequently things you are contractually not free to share. Convert them in advance — percentages instead of absolutes, "a large logistics customer" instead of the name — because hedging invented on the spot sounds like evasion, whereas "I'll describe the shape rather than the numbers" sounds like someone who can be trusted with the next employer's confidences too.