The behavioural interview: how to prepare

What it is

The part of an interview that asks not about code but about behaviour: how you acted in specific situations. "Tell me about a time you made a mistake." "What did you do when you disagreed with a colleague?"

The logic is simple: past behaviour predicts future behaviour better than promises. They ask what happened, not what you'd hypothetically do.

What's being assessed

• Whether you can admit mistakes. Someone for whom "everything always worked out" is a warning sign.
• How you handle disagreement. On the substance, or personally.
• Whether you ask for help. Someone who grinds alone for a week is expensive for a team.
• Whether you can explain. How clearly you describe what you did.

An answer template

Four steps, ninety seconds to two minutes total:

1. Situation. Briefly, enough to place it. 2. Task. What had to be done and where the difficulty was. 3. What you did. You specifically, not "we decided". This is the main part. 4. How it ended. The outcome and what you took from it.

That last point is often skipped and is the most valuable: a conclusion shows you can learn from your own experience.

Standard questions and what sits behind them

"Tell me about a mistake." Testing honesty. They want a real mistake with consequences and a lesson. "I work too hard" is a fail.

"A conflict with a colleague." Testing whether you can disagree without hostility. A good answer ends in a resolution, not a victory.

"A problem you couldn't solve." Testing whether you know when to ask for help.

"What did you do when you ran out of time?" Testing whether you can cut scope and warn people early.

Where to find examples without a job

Anything involving working with people counts: a team study project, a hackathon, volunteering, a previous job outside the field.

On conflict, for instance: "On a project the three of us spent a week arguing about which library to use. In the end we agreed a rule: if half an hour doesn't settle it, we take the one most of us know. The argument ended and the work moved."

That's a genuine example of teamwork, and it answers better than any theory.

Why invented stories show

Because follow-up questions come: what did your colleague say, why did you decide that, what happened afterwards. A real story has detail; an invented one runs out at the second question.

So don't invent. Better to recall a genuine if modest episode.

How to prepare

Write out three or four stories from your own experience: a mistake, a disagreement, a time you got stuck, and a time something worked. Four template points each.

You don't need more: almost every question reduces to those four plots, and one story often serves several questions at once.