Skip to main content
  1. Posts/

Using the STAR Method for Developer Interviews

· loading · loading ·
Jared Lynskey
Author
Jared Lynskey
Emerging leader and software engineer based in Seoul, South Korea

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. STAR stands for Situation, Task, Action, Result: you ask for a real story from the candidate’s past and steer them 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:

CompetencyQuestion
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.

Further Reading
#

On this site:

Elsewhere: