The STAR method for software engineers

Behavioural interviews trip up engineers who are otherwise well prepared. The technical rounds have a shape you can practise; "tell me about a time you disagreed with a teammate" feels like it has no shape at all. So people ramble through the background, run out of time before the interesting part, and say "we" so often that the interviewer can't tell what they personally did.

The STAR method fixes most of that. It's a simple structure for telling a story from your work: Situation, Task, Action, Result. This guide covers how to use it as an engineer, how to choose and prepare your stories, and how to handle the follow-up questions that come after the rehearsed part runs out.

What the behavioural round is testing

A behavioural or leadership round uses stories from your past to predict how you'll work in this job. The interviewer usually has a short list of competencies to assess, things like:

• Ownership: decisions you made and outcomes you took responsibility for
• Collaboration: handling disagreement and influencing people you don't manage
• Dealing with ambiguity: making progress when the problem or the requirements weren't clear
• Growth: what you learned from setbacks and what you changed afterwards
• Scope: whether the size of your stories matches the level of the role

Each question maps to one or two of these. "Tell me about a time a project didn't go to plan" is asking about ownership and growth. "Tell me about a time you had to convince another team" is asking about influence. Knowing which competency a question is after tells you which part of your story to spend time on.

The STAR method, applied to engineering stories

Situation: short, and only what's needed

The examples below follow one illustrative story through all four parts.

Give the interviewer just enough context to follow the rest: the team, the system, and what was going on. Two or three sentences.

"I was on a four-person team that owned the checkout service. We'd just moved it onto a new database, and a few weeks later checkout latency started spiking during evening peaks."

The common trap is spending two minutes on architecture and history. The interviewer isn't assessing the situation; they're assessing what you did in it.

Task: your responsibility, not the team's

Say what was yours to solve, and why it mattered.

"I'd led the migration, so I took ownership of finding the cause. It mattered because the spikes lined up with our highest-revenue hours."

This is also where you set the scope. A task like "fix the bug assigned to me" and a task like "decide whether to roll back a migration two teams depended on" signal very different levels.

Action: most of the answer goes here

This is the part interviewers care about most, and the part most answers rush. Walk through what you did, in order, with the reasoning behind each step:

"First I compared query plans before and after the migration and found that two of our hottest queries had lost an index the old database had created implicitly. Adding the indexes was the obvious fix, but they were large tables and building them would lock writes. So I proposed building them concurrently during a low-traffic window, wrote the runbook, and got the other team that read from those tables to sign off on the timing. I also added a check to our migration tooling that compares index coverage between environments, so we'd catch the same gap next time."

Notice what's there: specific decisions, the reason for each, a tradeoff ("building them would lock writes"), working with another team, and a step that prevented the problem recurring. Notice also the word "I". When you were part of a team, say "we" for what the team did and "I" for your own decisions and actions. Interviewers ask "what did you do?" because team stories so often hide the individual.

Result: the outcome, then the reflection

Say what happened, with numbers if there were numbers and you know them.

"The evening spikes stopped after the indexes went in, and p95 latency went back to what it had been before the migration. The index check caught a similar gap in another service's migration a couple of months later."

Then add a short reflection: what you learned, or what you'd do differently. It's not formally part of STAR, but it's often what prompts the best follow-up, and it shows you think about your own work.

"Looking back, I'd have done the index comparison as part of the migration plan rather than after an incident. That's now in our checklist."

Choosing your stories

You don't need a story for every possible question. Six to eight strong stories usually cover most of what you'll be asked, because one story can answer several prompts. A project that went wrong might cover conflict, a setback, and ownership, depending on which part you emphasise.

Good stories have:

• A real decision you made, with alternatives you considered
• Some difficulty: a constraint, a disagreement, a mistake, or uncertainty
• Your part clearly visible, not just the team's
• An outcome you know, including what happened after the project ended
• Recency, ideally from the last few years

Make a small table of your stories against the competencies, and look for gaps:

If a column is empty, find a story for it before the interview, not during it.

Calibrate to the level

The expected scope grows with seniority. For a mid-level role, a story about owning a feature end to end and working through a disagreement with a teammate is right. For a senior or staff role, the interviewer expects stories with influence across teams, decisions with long-term consequences, mentoring, and setting direction with little guidance. A story that suits one level may need a bigger frame, or a different story altogether, for another. The job description's scope words ("own", "lead", "across teams") are a good guide; our post on preparing from the job description covers reading them.

Questions about disagreement

"Tell me about a time you disagreed with a colleague" is one of the most common behavioural questions, and one of the easiest to get wrong. The traps are picking a disagreement where you were simply right and the other person was simply wrong, or one so mild there was nothing to resolve.

A good disagreement story shows:

• That you understood the other view. Say what the other person wanted and why it was reasonable from where they stood.
• How you engaged with it. Data, a prototype, a written proposal, a conversation one to one: something more than arguing louder.
• How it was resolved. Sometimes you persuaded them, sometimes they persuaded you, and sometimes you disagreed and committed. All three are fine stories if you handled it well.
• What happened to the working relationship. Interviewers want to know you can disagree with someone and still work with them the next day.

Questions about setbacks

"Tell me about a time you failed" makes people nervous, so they pick a story where nothing really went wrong. That reads as evasive. Choose a real setback where you played a meaningful part, be honest about what happened, and spend most of the answer on what you did about it and what you changed afterwards. The reflection is the point of the question.

What to avoid: stories where the setback was entirely someone else's doing, and stories that end with the problem but not with what you learned from it.

The follow-ups

A rehearsed STAR answer is only the start. Good interviewers dig past it, because follow-ups are how they check that a story is specific and genuinely yours:

• "What did you do, specifically, versus the rest of the team?"
• "What else did you consider? Why didn't you do that?"
• "How did you know it was the right call at the time?"
• "What did the other person think? Did they agree in the end?"
• "If your manager were here, how would they describe what happened?"
• "What would you do differently now?"

You can't rehearse every follow-up, but you can prepare for them by knowing each story well: the alternatives, the people involved, what happened afterwards, and an honest answer to "what would you do differently?". If you were there and you've thought about it, the follow-ups are easy. If you're stretching a story, they're where it shows.

How to practise behavioural answers

• Write bullet points, not scripts. A script sounds like a script. Bullets for each STAR part keep the structure while letting you tell it naturally.
• Say each story out loud and time it. Two to three minutes for the main answer is a good target. Most first attempts run long, almost always in the situation.
• Practise with follow-ups. Ask someone to interrupt with "what did you do?" and "why?". It's the closest you'll get to the real round without being in it.
• Practise adapting. Take one story and tell it as an answer to three different questions, shifting the emphasis each time.

The same structure helps in other rounds too. In a technical deep-dive you'll explain a project in more depth; in a system design round, the habit of giving a reason for every decision carries straight over (see our system design framework).

Hardmode's leadership and behavioural round picks the competencies the job description signals and asks the follow-ups a good interviewer would, so you can find where a story needs more detail before the interview finds it for you.