The STAR interview method is a way of asking behavioural questions about what a candidate has actually done, rather than what they say they’d do. You ask for a real example, such as “Tell me about a time you influenced a technical decision without direct authority”, and listen for four parts: the Situation, the Task they were responsible for, the Action they took themselves, and the Result. I use it for developer interviews, and the follow-up questions do most of the work.
Since moving into an engineering management role this year I’ve spent a lot more time on the hiring side of the table, and the biggest lesson so far is that letting a candidate talk generally about their CV tells you almost nothing. A resume says what someone worked on. It says very little about how they work.
Behavioural questions in the STAR format are the best tool I’ve found for closing that gap: a real story from the candidate’s past, steered through those four beats. It sounds like HR boilerplate — it is HR boilerplate — but it forces specifics, and specifics are where the signal is.
The shape of a good answer#
Take a question like “Tell me about a time you resolved a complex bug.” You’re listening for the situation (what was going on and why it mattered), the task the candidate was personally on the hook for, the actions they took — the “I”, not the “we” — and the result, ideally with a number attached.
A strong answer sounds something like this one, about technical debt:
“Our deployment pipeline took 45 minutes, and flaky tests meant developers often re-ran builds several times. I tracked the time lost over a month — roughly 15 hours per developer. I presented that to leadership and proposed a two-sprint investment to parallelise the tests and fix the flakiest ones. Deployments dropped to 12 minutes, and our deployment frequency doubled.”
Situation, task, action, result, in five sentences, with the candidate’s own contribution unmistakable. Put that next to “we had a slow pipeline so we fixed it” and you can see why the structure earns its keep.
The questions I keep coming back to#
Rather than trying to cover everything, I organise questions around the competencies the team actually needs right now:
| Competency | Question |
|---|---|
| Problem-solving | “Tell me about a time you debugged a production issue under pressure.” |
| Collaboration | “Describe a project where you had to work with a difficult stakeholder.” |
| Technical leadership | “Tell me about a time you influenced a technical decision without direct authority.” |
| Learning agility | “Describe when you had to get up to speed on unfamiliar technology, fast.” |
| Ownership | “Tell me about a time something you built failed. What did you do?” |
That last one is my favourite. How someone talks about a failure tells you more than three success stories, and it’s very hard to rehearse.
Where the interview actually happens#
Candidates rarely give you the full STAR arc unprompted, and that’s fine — the follow-ups are the real interview. If someone says “we improved performance”, ask by how much and how they measured it. If everything is “we”, ask what they personally did. If a story wraps up suspiciously neatly, ask what they’d do differently next time.
The other thing that took me a while to learn: ask the same questions of every candidate and score the answers against a simple rubric. It feels mechanical, but it’s the only fair way to compare people. Otherwise you just end up favouring whoever you spoke to most recently.
None of this replaces a technical assessment — you still need to see whether someone can build things. But hypotheticals are easy to bluff and past behaviour is hard to fake. After a year of running these, I trust a well-probed story far more than a polished answer about strengths and weaknesses.
STAR in four lines#
- Situation: what was going on, and why it mattered.
- Task: the part the candidate was personally responsible for.
- Action: what they did themselves. If it’s all “we”, ask what they did.
- Result: what came of it, ideally with a number. If they say they improved something, ask by how much and how they measured it.
Further Reading#
On this site:
- The Coffee Chat: A Precursor to the Hiring Process — getting to know candidates before the formal process starts
- Prioritizing Team Dynamics in Engineering Management — hiring for how someone will fit the team
- The Benefits of Interning at a Startup — useful context when evaluating early-career candidates
- Retrospectives: The Power of Feedback Loops — the same feedback habits apply to your interview process
Elsewhere:
- The STAR Method: The Secret to Acing Your Next Job Interview — The Muse’s guide, written for candidates
- Google re:Work: Structured Interviewing — the research behind structured interviews
- First Round Review: 40 Favorite Interview Questions — good for stealing
- Joel Spolsky: The Guerrilla Guide to Interviewing — a classic that still holds up