Preparing stories and practising for real
By the end: You have a bank of real stories that answer the common questions, and a practice routine that exposes your weak spots.
- A story bank
- Structure without sounding rehearsed
- Numbers and your own role
- The questions behind the questions
- Mock interviews that help
New to interviewing well? Interviewing well is a separate skill from the engineering being tested, and it is made of specific, practisable habits: narrating your reasoning aloud instead of going quiet, asking what the constraints are before designing anything, checking your own answer before declaring it finished, and arriving with about eight short true stories ready, covering a conflict, a failure, an ambiguous brief and something you would now do differently. Why it matters
Behavioural questions come from a short and predictable list, and the reason capable engineers answer them badly is that they improvise. This section builds a bank of six to eight real stories from your own work, each written so it can answer several of those questions, with a number in it and your own part separated from the team's. The second half is the practice routine: out loud, recorded, fixing one thing at a time. The gap between knowing a story and telling it well is larger than it feels from the inside.
Build a story bank#
Behavioural questions repeat: a hard technical problem, a disagreement, a failure, a time you led, a time you changed your mind. Write six to eight real stories from your work, each of which can answer several of these.
Story: RAG answers going stale
Situation support bot cited archived articles, 17 of 48 failures
My part found it in trace review, proposed excluding archived docs
Result held-out pass rate 10/24 -> 17/24, cost +8%
Answers hard problem, using data, influencing without authorityWrite each one on a single index card in that format, and keep the cards. The point of the format is that it is too short to hide in: if you cannot name your part in one line, you do not have a story, you have a project you were near. Six to eight cards covers the question list with redundancy, which matters because a loop will sometimes ask two questions that your best story answers and you cannot tell it twice.
A bank that covers the list, with no story used twice:
card answers
index went stale hard problem, data, influence
argued against the rewrite disagreement, changed my mind
I shipped a bad migration failure, ownership, what I changed
took over the on-call rota leadership without the title
the eval nobody wanted persuading, long-horizon work
the feature we cancelled judgement, saying no
the intern's first PR mentoring, giving feedback
the Friday outage pressure, communication under stress
The gaps in that table are what to go looking for. Most people
have four cards that are all "hard technical problem" and
nothing at all for disagreement or for feedback.Structure, and what each part is for#
Context in two sentences, what you did in most of the time, the result with a number, what you learned. The most common mistake is spending two minutes on context and thirty seconds on your actions. Interviewers are scoring what you did.
part length what it must contain what it is for
situation 2 sent. why this was hard makes the rest legible
and who cared
task 1 sent. what you specifically establishes ownership
were on the hook for before any actions
action 60-70% decisions, alternatives, this is the part being
what you rejected and why scored. All of it.
result 1-2 a number, and what it makes it verifiable
meant for someone
reflection 1 sent. what you do differently reads as seniority
Three minutes total. If your situation is longer than thirty
seconds, you are explaining your old company rather than
answering the question.One story, written out#
Here is the card above told properly, at the length it should actually take, with what each part is doing beside it. Read the right-hand column first if you want to see the machinery.
"Our support bot was answering confidently SITUATION. Two sentences,
from articles we had archived two years and it names who was hurt
ago. Customers were getting instructions rather than what the stack
for a product page that no longer existed, was.
and we found out from a complaint rather
than from a dashboard.
I owned retrieval quality. Nobody had asked TASK. "I owned" in the
me to look at this -- the ticket was filed first four words. Note the
against the support team." second sentence: it says
the work was not assigned,
which is the whole reason
this answers "influencing
without authority" too.
"I started by counting rather than guessing. ACTION, and it opens with
I pulled the last hundred conversations the a method, not a fix. This
support team had flagged and read the traces, is the sentence that most
and 17 of 48 failures cited a document that candidates skip.
was archived. That made it the largest single
cause, ahead of the retrieval problems I had A number, and what the
assumed were dominant. number displaced. The
comparison is what makes
it a finding.
I proposed the cheap fix first: exclude Decision, with the
archived documents at index time. The alternative named. An
alternative was a freshness score in the interviewer is listening
ranker, which is better in principle and for exactly this.
would have taken a sprint. I argued for the
exclusion because we could ship it in a day And the reason for the
and measure whether staleness was really the choice, which is a
problem before building the ranking work. reason about evidence
rather than about effort.
The part I got wrong was that I assumed the
archive flag was reliable. It was not -- about Volunteers a mistake
a tenth of the archived set had been unprompted, inside the
mis-flagged during a migration, and my first story. This is worth more
version dropped good articles. I caught it than the fix is.
because the eval score went down, not up,
so I added a check that the article had not Caught it with a
been viewed in six months as a second signal." measurement, not by
noticing. That is the
detail that makes the
story true.
"Held-out pass rate went from 10 of 24 to 17 RESULT. A number, and the
of 24. Token cost went up eight per cent cost of getting it. Giving
because the retrieved documents were longer. the cost is what stops this
We shipped the freshness ranker a quarter reading as a sales pitch.
later, on evidence rather than on my hunch.
What I would do differently: the reason we REFLECTION. Names a
learned about this from a customer is that change to the system, not
we had no measure of answer staleness at a promise to be careful.
all. I would put a cheap check on document
age into the eval set on day one now."Nothing in that story is impressive on its own. The archived-document bug is mundane, the fix is a filter, and the whole thing took a week. That is the point: a good behavioural answer is not made of a good project, it is made of visible reasoning applied to an ordinary one. Candidates who believe they have no stories almost always have this and have discarded it as too small.
The two ways a story fails#
Both failures are invisible to the person telling the story, because from the inside both feel like modesty or like staying on topic. Here they are side by side with the same underlying week of work.
NO CONFLICT
"We noticed some answers were citing old articles, so we filtered
out archived documents at index time and the pass rate improved."
What is missing: nothing was hard. No decision was made, no
alternative was rejected, nothing went wrong, nobody had to be
persuaded. There is no conflict, so there is nothing to score.
What the interviewer writes: "worked on retrieval. Could not
identify a decision. Ask again with a harder prompt."
The fix is not a bigger story. It is naming the fork: the
sprint-long ranker you did not build, the flag you trusted that
was wrong, the person who wanted to do it differently. Every
real week contains at least one.
NO PERSONAL CONTRIBUTION
"We were seeing stale answers, so we reviewed traces and found
archived documents were the main cause. We decided to exclude
them, we validated it against our eval set, and we got the pass
rate up to 17 out of 24."
Every sentence is "we". The story is good and the candidate is
invisible. Worse, it now sounds like a hedge: an interviewer
who hears seven "we"s in a row starts wondering which parts
were not yours, and will spend the follow-ups finding out.
What the interviewer writes: "strong project, unclear role.
Probe ownership."
The fix is one pass over the story replacing "we" with "I", "a
colleague" or "the team", whichever is true. Naming what
somebody else did is what makes the "I" believable -- a story
where you did everything is its own warning sign.Say 'I', and be exact#
'We built a pipeline' tells the interviewer nothing about you. Say what you personally did, what others did, and what you decided. Be honest about the parts you did not own; follow-up questions will find them anyway.
Exactness applies to the numbers too, and in the other direction from what people expect. A figure you are sure of is worth more than a bigger one you are guessing at, because the follow-up is always how you measured it. If you genuinely do not remember, say the shape and say that: it roughly halved, and you can describe the query you ran to know that. Inventing a precise number you cannot defend is the fastest way to lose a round you were winning.
What they are really asking#
- 'Tell me about a failure' asks whether you take responsibility and learn, not whether you have failed.
- 'A disagreement' asks whether you can disagree with evidence and still work together. The ending matters: a disagreement where you were persuaded is a better answer than one where you won.
- 'Something you are proud of' asks what you consider good work.
- 'A time you had to make a decision without enough information' asks whether you can act under uncertainty and say what would have changed your mind.
- 'Tell me about a conflict with a colleague' asks whether you can describe someone you disagreed with fairly. Describing them unfairly is the whole answer.
- 'Why this company' asks whether you have thought about it for more than five minutes.
Notice how many of these are asking about the same thing from different angles, which is whether working with you would be pleasant when things are going badly. That is most of what a behavioural round is for, and it is why the details people leave out as unflattering are usually the ones that score.
Mocks that help, and mocks that comfort#
Most mock interviews are useless in a specific and predictable way: a friend who likes you asks a question, you answer it, they say that was good, and you both feel prepared. A useful mock is uncomfortable on purpose, and the discomfort comes from structure rather than from the person being harsh.
Rule Why
They do not know the story A friend who already knows the
beforehand. project fills in your gaps
silently. A stranger cannot.
They must interrupt twice. Real interviewers do. Being
interrupted mid-story and
recovering is the skill.
They must ask two follow-ups The first answer is rehearsed.
on your weakest claim. The third is where you actually
find out what you know.
They write, and do not react. No nodding, no "great". Silence
is what the room feels like.
Timed, and stopped at time. A story that needed five minutes
is a story you have not finished
writing.
Feedback is three sentences, More than one thing to fix is
one of which is what to fix. nothing to fix.
Recorded, and you watch it The recording is where the
alone afterwards. learning is. The mock is only
how you generate it.Weekly is the right cadence in the final month, alternating coding, design and behavioural rather than doing your favourite one three times. Exchange with someone at a similar level and take both roles, because interviewing somebody else for forty minutes teaches you more about what reads as competent than being interviewed does. Sit through one silence as the interviewer and you will never let one happen as the candidate.
One fix per session
After each mock, write down a single thing to change and change only that in the next one. Lists of six improvements produce none, because under pressure you revert to habit and habit changes one item at a time. Filler words, then the missing numbers, then the ratio of context to action, then the pronouns -- four sessions, four fixes, and the answers are unrecognisable.
Practise out loud, with feedback#
- 1.Answer every story out loud and record it. Listen back; you will hear the filler and the missing numbers.
- 2.Do mock interviews with another person at least weekly in the final month, for coding, system design and behavioural rounds.
- 3.After each mock, write down one thing to fix, and fix only that in the next one.
- 4.Practise coding while talking. Silence is the most common reason a correct solution scores poorly.
- 5.Time one telling of each story. Anything over three and a half minutes is being cut by the interviewer, and they will cut the part you cared about.
Where people go wrong
Memorising answers word for word. They sound rehearsed, and they break at the first follow-up question.
If this comes up in an interview
Tell me about a time you were wrong about a technical decision.
Pick a real one where the decision mattered. Say what you believed and why it was reasonable at the time, what evidence showed you were wrong, what you did about it, and what you do differently now. The learning is the point of the answer.
Then they push further
What would you do differently if you faced that decision today?
Name a concrete change in how you decide, such as prototyping before committing, or setting a measurable check that would have caught it earlier. A general 'I would be more careful' scores poorly.
What gets marked up. Strong answers own the mistake without excuses, show the evidence that changed their mind, and end with a specific change in behaviour.
Walk me through a project you are proud of.
Two sentences of context, then the hardest problem and how you solved it, your decisions and the alternatives you rejected, and the result with numbers. Be ready to go deep on any part, because the interviewer will choose one.
Build this: Write six stories in the format above from your own work or projects. Record yourself answering five common behavioural questions using them, listen back, and rewrite the weakest two.
Watch it explained
This is one section of Interviewing well, 20 hours across 5 sections. Read it in full to get the whole topic in order.
Stop 50 of 50 on the AI Engineer route
0 of 50 topics done · 0h behind you, 603h to go
That is the last stop on this route. What remains is the part no syllabus can do for you: build the projects, and apply.
What you have marked done is stored in this browser only. It does not reach a server, and clearing site data will clear it.