The Behavioural Round: STAR Stories for Engineers

Engineers often treat the behavioural round as the easy part and prepare for it least. It is frequently where offers are decided, because technical rounds mostly confirm whether you can do the job while this one decides whether people want to work with you on it.

The structure#

The Action section is the one being scored. Most candidates invert this, spending a minute on background — the interviewer does not need the org chart, they need to know what you did and how you decided.

BAD  (all situation, no decision)
"So we had this legacy system, it was built about eight years ago by a team
that had left, and it used an old version of Spring, and there was this
service that did payments, and the database was Oracle at the time..."
 
GOOD (context in one breath, then the decision)
"Payment reconciliation ran nightly and had started overrunning into business
hours — four hours for 2 million transactions. I owned fixing it.
 
I profiled it first rather than guessing, and found 80% of the time was in
one N+1 query loading each transaction's line items individually. I fixed it
with a batch fetch, which took it to 40 minutes. Then I found the remaining
bottleneck was single-threaded processing, so I partitioned by account id
across eight workers — 12 minutes.
 
I also added a duration metric with an alert at 30 minutes, because the
original problem had grown gradually over a year and nobody noticed until it
was already overlapping the trading day."

The second version contains a decision, a method (profile, do not guess), a number at each stage, and a prevention step. It is also shorter.

The six stories#

Prepare these six and you can answer almost anything by selecting and reframing:

1. A hard technical problem you solved. Ideally a production incident — the incident playbook has the structure. Shows depth and diagnostic process.

2. A time you disagreed with someone. Shows how you handle conflict. Must end in a decision, ideally one where you either changed your mind on evidence or persuaded someone with it.

3. A failure, or something you got wrong. Shows self-awareness. Must be a genuine failure with a genuine consequence, and must end in a changed behaviour.

4. Something you led or drove. Shows initiative and scope. Does not require a title — "I noticed X, proposed Y, got agreement, delivered it" is leadership.

5. Working with a difficult constraint or deadline. Shows judgement under pressure and how you decide what to cut.

6. Something you learned or taught. Shows growth and whether you make the people around you better.

Most behavioural questions are one of these six in different words. "Tell me about a time you had to influence without authority" is story 2 or 4. "Tell me about a time you had to make a decision with incomplete information" is story 1 or 5.

Quantifying honestly#

If you genuinely do not have a number, say what changed qualitatively and be honest about the uncertainty: "I do not have the exact figure, but the on-call pages for that service essentially stopped — I remember because it was the first quarter I was not paged at night." That is credible. Inventing a precise number is not, and it tends to unravel when they ask how it was measured.

Surviving the follow-ups#

Every story gets two or three probes. They are the real test, because prepared answers survive them and invented ones do not.

"Why did you choose that approach over the alternative?"
"What would you do differently now?"
"How did you know it worked?"
"Who disagreed with you, and how did you resolve it?"
"What was the hardest part?"
"What did that cost — what did you have to give up?"

Prepare for these explicitly. For each of your six stories, be able to name: one alternative you considered and why you rejected it; one thing you would do differently; how you measured the result; and one person who pushed back.

That last one matters. A story with no disagreement in it reads as either trivial or reconstructed — real engineering work has friction.

The conflict question#

The failure mode is a story where you were simply right and the other person came round. Nobody believes it, and it demonstrates nothing.

Situation  "A colleague wanted to introduce a new message broker for a
            feature that produced about 50 events a day."
 
Task       "I thought the operational cost was not justified, but he had
            more context on the roadmap than I did."
 
Action     "Rather than argue in the review, I asked what the twelve-month
            plan for that pipeline was — and it turned out three more
            producers were coming, which changed the volume estimate by two
            orders of magnitude. I still pushed back on the timing, and we
            agreed to ship the simple version first and revisit at the next
            producer. I wrote the trade-off into an ADR so the decision was
            not lost."
 
Result     "We shipped six weeks earlier. The broker went in four months
            later when the volume actually justified it, and the ADR meant
            nobody had to re-litigate the original decision."

That answer shows curiosity before judgement, a changed position on new information, a compromise, and a durable artefact. It also does not require anyone to have been wrong.

The failure question#

Not a trap, and not an invitation to a disguised strength. "I work too hard" fails this question outright.

1. A real failure with a real consequence.
   "I deployed a schema migration on a Friday afternoon that locked a table
    for eleven minutes during peak traffic."
 
2. Own it. No blaming the process, the pressure or someone else.
   "I had run it on staging where the table had 10,000 rows. Production had
    40 million. I did not check."
 
3. What you learned, specifically.
   "That staging data volume is not a test of a migration — the query plan
    is different at scale."
 
4. What you changed, concretely.
   "I wrote a migration checklist for the team: estimate the row count,
    check whether the operation takes a lock, use CREATE INDEX CONCURRENTLY,
    and never deploy schema changes inside the peak window. We have used it
    for every migration since."
 
5. Evidence it stuck.
   "We have done about thirty migrations since with no locking incidents."

Steps 4 and 5 are what convert a mistake into a positive signal. Everyone has broken production; the question is what the team got out of it.

Company-specific framing#

Some companies publish explicit behavioural criteria — Amazon's Leadership Principles are the most formalised, and interviewers there score against a specific principle per question. Where that is the case, read them and map your six stories onto them in advance.

Elsewhere the underlying dimensions are much the same: ownership, judgement, collaboration, dealing with ambiguity, and raising the bar. You do not need different stories, only different framing.

Practical preparation#

Write the six stories out in full, once. Not to memorise — to find the gaps. You will discover that two of them have no number, and one has no clear action, and that is exactly what the exercise is for.

Then say each one out loud with a timer. Two minutes is much shorter than it feels, and the first attempt at any story is usually four.

Finally, prepare your own questions. "What does the on-call rotation look like?", "What is the deployment frequency?", "What is the largest piece of technical debt the team is carrying?" Those tell you whether you want the job, and asking them signals you are evaluating rather than only hoping to pass.