Behavioural interviews in the AI era

Anyone can get a polished STAR answer in thirty seconds now, so interviewers have mostly stopped listening to it. The offer, or the senior title, gets decided at the second and third follow-up. That's the part no model can write for you. You either lived it and thought about it afterwards, or you go quiet.

The outage story that went quiet at the second follow-up

Earlier this year I interviewed a mid-level backend engineer and asked about an incident they'd led. The answer was flawless. Checkout went down after a deploy. They opened the incident channel, found connection pool exhaustion, added a circuit breaker, wrote the postmortem, and cut a reliability metric by a nice round number. Situation, Task, Action, Result, all in under two minutes.

First follow-up: 'What was the first thing you tried?' They said they followed the incident runbook. Second follow-up: 'What did you believe at minute ten that turned out to be wrong?' Silence. Then: 'I think we were pretty aligned as a team.' Nobody is aligned at minute ten of an outage.

I'd seen that shape before. A few weeks earlier a mentee showed me an interview prep doc they'd generated with an LLM. Same three-beat structure. Same 'I took ownership of communication' line. Same round-number result. Not one wrong turn, and real incidents are full of them. The candidate had probably been on that incident. But they'd prepared the summary instead of the experience, so the summary was all they had to give me.

What changed: STAR is free now

STAR (Situation, Task, Action, Result) worked as a filter for a long time. To tell a clean STAR story you had to reflect on your own work, figure out what caused what, and put it in order. People who could do that usually learned from experience, so a clean story was a weak signal, but a real one.

That signal is gone. Paste a few bullet points into ChatGPT or Claude and you get a structured, confident, metric-backed answer in seconds. Good interviewers have caught up. They treat your first answer as background, a map of the territory, and do the actual interviewing in the follow-ups.

• Before: a polished story was evidence that you could reflect.
• Now: polish is free, so it tells the interviewer nothing.
• What still costs something is specific detail under pressure. Who said what, what you got wrong, what you'd do with different constraints. You can only produce that fluently if you lived it and thought about it afterwards.
• In practice, a first answer that's 70% as polished costs you almost nothing. Follow-ups that are 70% as deep cost you the offer.

The three-layer probe I actually run

I take every behavioural question three layers deep. A rehearsed story gets thinner at each layer. A real one gets more specific, more uncomfortable, and more interesting.

Here's the same checkout outage at each layer, with a rehearsed answer next to a real one.

Layer 1: The story

• Question: 'Tell me about an incident you led.'
• Rehearsed: 'Checkout failed after a deploy. I took ownership, coordinated the response, identified connection pool exhaustion as the root cause, and implemented a circuit breaker that improved reliability significantly.'
• Real: 'Checkout started timing out about fifteen minutes after a Friday deploy. I was on call. It turned out to be the DB connection pool, but that took us a while, and we didn't fix it the way I first wanted to.'
• What to notice: at this layer the real answer is often the rougher one, and that's fine. I barely score layer 1 anymore. Neither do the good interviewers I know.

Layer 2: The messy middle

• Questions: 'What did you try first? What broke? Who disagreed with you?'
• Rehearsed: 'We followed the incident process, gathered data, and the team quickly aligned on the root cause.'
• Real: 'I rolled back the deploy first because I was sure it was the cause. Nothing improved, and that cost us about twenty minutes. Someone on the platform team kept saying it looked like pool exhaustion from a batch job that had started at the same time. I pushed back because the timing matched the deploy so neatly. She was right. The thing I'm least proud of is that I asked our on-call agent to summarise the deploy diff, it confidently pointed at a query change, and I took that as confirmation of what I already believed.'
• What to notice: a wrong guess, the time it cost, a named disagreement, and a reasoning error the candidate made themselves. None of it sounds good. All of it is believable.

Layer 3: The counterfactual

• Questions: 'With half the time, what would you cut? Without the agent? If a different teammate had been on the call?'
• Rehearsed: 'I would communicate earlier, prioritise better, and make sure everyone was aligned.'
• Real: 'Without the agent I'd have been slower reading logs, but I also wouldn't have had my wrong theory confirmed so quickly, so I'm honestly not sure it helped overall. If the platform engineer hadn't been on the call I think we'd have tried a second rollback. With half the time I'd skip root cause and just raise the pool limit and pause the batch job, which is what we ended up doing anyway at minute forty.'
• What to notice: the real answer weighs tradeoffs, admits it isn't sure, and connects back to details from layer 2. Rehearsed answers stop at principles because there's nothing underneath them to reason from.

The new question: 'When did AI-generated code break something?'

Expect some version of this more and more: 'Tell me about a time you shipped AI-generated code that broke something. How did you find out?' It's the modern 'tell me about a failure', and it's harder to fake, because it's a question about your judgement. The model's isn't on trial.

Weak answers blame the tool. 'The model hallucinated an API, so now I always double-check AI output.' That tells me nothing about you. Every engineer already knows models are sometimes wrong. What the interviewer wants to hear is why your trust failed at that particular moment.

Strong answers walk through your own trust failing:

• What made it look right. Tests passed, the diff was small, the explanation sounded confident, it was 6pm.
• What you skipped because of that. Maybe you didn't run it against production-shaped data, or you skimmed the migration, or never read the generated test assertions.
• How you found out, and how late: a customer ticket, an alert, a teammate's review two days later. The longer it took, the more there is to learn.
• What you changed in your own process, and it has to be specific. 'I now read generated tests before generated code, because twice the tests were asserting the bug' is an answer. 'I'm more careful now' isn't.

Strong answer, compressed:

"An agent wrote a pagination fix for our export endpoint. CI was green and the
diff was 40 lines, so I approved it in about five minutes. What I didn't check
was that the generated test used a fixture with 3 rows. Real exports had
thousands of rows, and the cursor logic skipped one row per page boundary.
We found out a week later when finance reconciled numbers and they didn't
match. My mistake was letting 'green CI' stand in for 'I understand this
change.' Now, for any agent PR that touches data correctness, I read the
tests first and ask what they don't cover before I read the implementation."

What interviewers actually score now: calibrated distrust

Calibrated distrust means noticing early that confident work is wrong, whether it's yours, a colleague's, or an agent's, and acting on it even when nobody is watching. It isn't blanket suspicion. That just slows everything down. You check in proportion to the real risk of the work, not to how confident the output sounds.

• Early: you caught it in review or at minute ten, not in the postmortem.
• Confident work: the dangerous mistakes look finished, and agent output almost always looks finished.
• Yours included. The strongest signal is a candidate who distrusted their own confident theory, like the rollback in the outage story.
• Nobody watching: rejecting a green-CI agent PR at 6pm is invisible work. Interviewers are trying to find out whether you do it anyway.

A side note on the old rubric. Classic behavioural scorecards ask about conflict ('disagreed with a colleague') and ownership ('took charge'). Both assume the friction that matters is between people and the action that matters is visible. On an AI-first team, a lot of the friction is between you and a confident tool, or between you and your own first guess. And the action that matters is often quiet: not merging something. A rubric that only scores interpersonal conflict and visible ownership will miss the engineer who quietly stopped three bad agent PRs last month.

The prep exercise: build depth, not polish

Take the 5 stories you pulled out of your brag doc earlier in this series. Fill in the template below for each one, by hand. Don't use AI for this step. Struggling to remember is the whole point.

## Story: <one-line title>

Layer 1 (30 seconds max):
- What happened, what I did, what changed.

Layer 2: the messy middle
- Dead end: what I tried first that didn't work, and how long it cost.
- Disagreement: who pushed back, what they said, who turned out to be right.
- Over-trust: one moment I trusted a tool, agent, dashboard, or my own
  first theory more than I should have, and what gave it away.

Layer 3: counterfactuals
- Half the time/budget: what I'd cut.
- No agent/AI tools: what would be slower, and what might actually be better.
- Different teammate: whose absence would have changed the outcome, and how.
- What I'd do differently: one concrete change, not a principle.

Here's the rule. If you can't fill in the dead end, the disagreement, and the over-trust moment from memory, the story is too thin for a senior loop. It isn't a bad story. You were just too far from the details. Swap it for a smaller story you actually remember. A well-remembered story about a flaky test you chased for two days beats a vague one about the platform migration you were nominally part of.

• Have at least one story where the over-trust moment involves AI-generated code or agent output. You will be asked.
• Have at least one where you were wrong and someone else was right.
• Make the over-trust moments concrete, like 'the agent's summary', 'the green CI badge', or 'the p50 dashboard when the problem was in p99.'

Using AI in prep without it backfiring

The mistake is asking AI to write or polish your stories. That improves exactly the layer interviewers have stopped scoring. Worse, it can quietly overwrite your memory of what happened with a cleaner fiction, and then at layer 2 you're trying to recall a version that never happened.

Make the model the interviewer instead. It's good at relentless, specific follow-ups, and it doesn't get tired at depth three. Tell it explicitly not to improve your answers.

You are a senior engineering interviewer running a behavioural interview.
I'll tell you a story from my work. Your job is to probe it, not improve it.

Rules:
- Ask ONE follow-up at a time. Wait for my answer.
- Layer 2: ask what I tried first, what broke, who disagreed, and when I
  trusted a tool, an AI agent, or my own first theory too much.
- Layer 3: ask counterfactuals: half the time, no AI tools, a different
  teammate, what I'd change.
- If my answer is generic ("we aligned", "I communicated better",
  "I double-check now"), say so plainly and ask for a specific moment,
  name, or number.
- Do NOT rewrite, polish, or suggest wording for my answers.
- After layer 3, give me: (a) the point where my story got thinner,
  (b) any details that contradicted earlier ones, (c) one question a
  sharp interviewer would still ask.

My story: <paste your 30-second layer 1 version>

• Answer out loud first, then type it. Speaking exposes the gaps that typing lets you edit away.
• When the model flags an answer as generic, go back to the template and dig out the real detail yourself. Don't ask the model to supply it.
• Run each story twice, a few days apart. If your layer 2 details shift between runs, you're reconstructing, not remembering. Go find the facts in old Slack threads, PR comments, the postmortem doc.

If you sit on interview panels

All of this works from your very next interview.

• Keep layer 1 under two minutes. Let the candidate set the scene, then move on.
• Ask at least one layer 2 question every time. 'What did you believe at the start that turned out to be wrong?' is the best single filter I know.
• Ask one layer 3 counterfactual. 'Without the agent' and 'with a different teammate' work best.
• Put the AI-failure question in every senior loop: 'Tell me about a time you shipped AI-generated code that broke something. How did you find out?'
• Score the trajectory, not the polish. Note whether the story got richer, stayed flat, or got thinner from layer 1 to layer 3. A slightly awkward story that gets richer beats a perfect one that gets thinner.
• Score calibrated distrust explicitly. Did they catch it early? Did they distrust their own confident work? Did they act when nobody was watching?
• Don't punish an honest 'I don't know' at layer 3. Confident speculation is worse than calibrated uncertainty, and calibrated uncertainty is the skill you're hiring for.

Day 28 moves from getting the offer to negotiating it. The depth you built here carries over, because it's hard to lowball someone who can explain exactly what they did and why.

Extend your knowledge

• This week, fill in the depth template for all 5 brag-doc stories by hand. Then run the interviewer prompt on your two weakest, out loud.
• Read the 'Postmortem Culture: Learning from Failure' chapter in Google's Site Reliability Engineering book. Writing blameless postmortems is the best practice I know for building the layer 2 honesty interviewers want to hear.
• Annie Duke's 'Thinking in Bets' gives you a practical way to think about calibration. It separates decision quality from outcome and has you track how confident you were against how right you turned out to be.
• On panels, add the 'what did you believe that turned out to be wrong' question and the AI-failure question to your next three interviews. Write down each candidate's layer 1 to layer 3 trajectory, then compare those notes with your gut-feel scores.