Skip to content
Oleg Sotnikov
Book a Call
Free interview guide

The STAR Method for Interviews

Situation, Task, Action, Result. Four boxes that turn a vague answer into a story an interviewer can score. I have spent 25+ years on the hiring side of these conversations, and this is what works, plus what I hear go wrong every week.

Practice with a real interviewerFree tool, nothing uploaded: ATS resume checker

The STAR method is a way to answer behavioral interview questions in four parts: Situation, Task, Action, Result. Instead of describing how you generally work, you tell one specific story — where you were, what you were responsible for, what you personally did, and how it turned out. Oleg Sotnikov, a fractional CTO who has interviewed and hired engineers for 25+ years, wrote this guide to show what a scoreable answer looks like from the interviewer's side of the table.

Why Interviewers Ask Behavioral Questions

From the interviewer's chair the reason is narrow: past behavior is the only evidence in the room.

I can read your resume before the call. What I cannot read is how you behaved when the deploy failed at 2 a.m., or when a senior engineer stopped reviewing anyone's code. So I ask you to tell me about a time. The story is useful to me not because it is impressive, but because it is specific enough to check.

Most structured loops run on a scorecard: a few named competencies, each rated on evidence from the conversation. A vague answer leaves the interviewer nothing to write down. "I work well under pressure" is a claim about yourself. "Our checkout service started returning 500s on Black Friday and I was the on-call engineer" is the start of something that can be rated. STAR is not magic phrasing. It is the shape that gets the evidence out of you in the order the scorecard needs it.

Past behavior is the evidence

Nobody in the room can watch you work. The closest available substitute is a detailed account of how you worked before, told well enough that the details hold together under questioning.

Answers get scored, not admired

The interviewer is filling boxes while you talk — ownership, judgment, collaboration, whatever the rubric names. Give them sentences they can copy straight into the box.

Detail is the credibility test

Invented stories collapse under follow-up questions. Real ones get better: the numbers, the system names, the tradeoff you argued about. That difference is visible within two questions.

The Four Parts, and How Long Each One Runs

Most weak answers fail on proportion rather than content. Situation and Task are setup; Action and Result are the answer. Aim for roughly fifteen seconds, fifteen seconds, sixty to ninety seconds, thirty seconds.

S

Situation — set the scene, then stop

One or two sentences of context: where you worked, what the system or team was, and what was happening. The interviewer needs just enough to follow the story. If they want the org chart, they will ask for it.

Do

  • Compress the setup into one clause: "at a 30-person fintech I was the on-call backend engineer."
  • Anchor it in time — a release, a quarter, an incident — so the story has edges instead of being a general period of your life.
  • Pick a moment where something was actually at stake. That is the raw material the rest of the answer runs on.

Avoid

  • Do not walk through the product roadmap, the reorg history, or who reported to whom.
  • Do not spend two minutes here. An interviewer who hears three minutes of setup has stopped listening before you reach what you did.
  • Do not open with "this was a really complex project" as a substitute for saying what the project was.
T

Task — your responsibility, not the team's

One or two sentences on what you were on the hook for. This is the part candidates skip, and skipping it makes the whole answer ambiguous, because I cannot tell whether you led the work or watched it happen.

Do

  • State your mandate plainly: "I owned the migration," or "I was asked to halve p95 latency before the enterprise launch."
  • Name the constraint that made it hard — a fixed date, a missing teammate, a system you were not allowed to change.
  • If you were not the owner, say what you were. A supporting role described honestly scores better than a leadership role that dissolves under questioning.

Avoid

  • Do not describe the company's goal and leave your own part implied.
  • Do not inflate the role. Two follow-up questions is usually all it takes, and the recovery costs more than the claim was worth.
  • Do not fold Task into Situation and rush past both to get to the interesting part.
A

Action — the longest part, in the first person

This is what you get scored on, so give it sixty to ninety seconds. Walk through what you did, in order, including the decisions you made and the options you rejected. Three or four concrete steps land better than ten vague ones.

Do

  • Say "I" for your own work and keep "we" for the moments the team genuinely acted together.
  • Name the tradeoff: what you chose, what you gave up, and why that was right with the information you had at the time.
  • Include the unglamorous parts — the rollback plan, the conversation you did not want to have, the test you wrote before the fix.

Avoid

  • Do not narrate the stack. The interviewer wants the decision: what you moved off the request path and why, not which queue you used.
  • Do not skip ahead to the outcome. Your judgment lives in the decisions, and the outcome alone does not demonstrate it.
  • Do not list every step you took. Pick the three or four a peer would recognize as the hard ones.
R

Result — how it ended, and what you took from it

Thirty seconds: the outcome, with a real number where one exists, plus one line on what you learned. If you cannot quantify the main result, quantify something next to it — time saved, incidents avoided, a practice the team still follows.

Do

  • Close in the same terms you opened with. If the task was p95 latency, finish on p95 latency.
  • Use the number you actually know. "From about eleven minutes to under two" is credible; "a 40% improvement" with no baseline is not.
  • Add a sentence of reflection: what you would do differently, or what the experience changed about how you work now.

Avoid

  • Do not end on "and it went well." That is the one sentence an interviewer cannot write on a scorecard.
  • Do not invent metrics. If the project was cancelled, say so and tell me what you learned — that is still a scoreable answer.
  • Do not append a second story as a bonus. One complete answer beats two half ones.

Three Worked Answers

These are illustrative, not client stories. The scenarios are deliberately generic — what matters is the shape and the level of detail, which you fill with your own material.

Engineer · incident response

Question: Tell me about a time you handled a production incident.

Situation
At a payments company of about sixty people I was the on-call backend engineer. On a Friday evening our checkout service started returning 500s on roughly one request in five, and the error rate was climbing.
Task
I owned the incident until it was resolved or handed over. The immediate goal was stopping the customer-facing failures; the root cause could wait.
Action
I declared an incident and posted in the shared channel so support stopped guessing at what customers were seeing. The dashboards showed the failures concentrated on one database replica, so I pulled that replica out of the read pool before I understood why — the error rate dropped to near zero within about four minutes. Then I looked properly. A schema migration that afternoon had left that replica without an index, so a query taking 8 ms elsewhere took several seconds there and exhausted the connection pool. I chose to rebuild the index rather than roll the migration back, because a rollback would have re-broken the feature the release had just shipped, and I wrote that reasoning into the channel so the decision was reviewable rather than mine alone. I drafted the postmortem the same evening while the timeline was still exact.
Result
Customer-facing errors lasted about eleven minutes and no payments were lost. The postmortem produced two changes I pushed through the following week: migrations now verify index presence on every replica before they are marked complete, and the read pool ejects a replica automatically when its latency crosses a threshold. What I took away is that mitigating first and diagnosing second is almost always right, and I have had to argue that with engineers who want the cause before they will touch anything.
Engineer · disagreement with a PM

Question: Tell me about a time you disagreed with a product manager.

Situation
I was the senior engineer on a four-person team building a reporting feature. Two weeks before the launch date our product manager added CSV export and scheduled email delivery to the same release.
Task
I was responsible for a date we had already promised three enterprise customers. My read was that the additions would either slip that date or ship broken, and I had to say so without turning it into a standoff.
Action
I did not argue in the planning meeting. I spent an hour breaking the two requests into the work they actually required — export was a day, scheduled delivery needed a job runner, retry handling, and a way to stop sending after repeated failures — and brought it back as a written estimate with the risks named next to each item. Then I offered choices instead of a refusal: ship export now and delivery two weeks later, or move the date and ship both. I asked which customer promise mattered more, because that was her call rather than mine. She picked export. I also asked for the delivery work to be written into the next cycle explicitly, so it would not resurface as a surprise a month later.
Result
We shipped on the original date with export included, and scheduled delivery went out sixteen days after that with proper retry handling. The habit stuck: for the rest of the year we costed late additions in writing before deciding on them, which took most of the temperature out of scope conversations. What I learned is that a disagreement lands better as a decision framed for the person who owns it than as a defense of my own estimate.
Engineering manager · underperformance

Question: Tell me about a time you managed someone who was underperforming.

Situation
I managed a team of seven at a Series B company. One engineer, about eighteen months in, had gone from steady to missing most of his commitments over a quarter, and two teammates had quietly started routing work around him.
Task
As his manager I was responsible for both outcomes: getting the team's delivery back, and giving him a genuine chance to recover before anything formal started.
Action
I looked at the work before I talked about it, so I was not arguing from an impression — his last quarter of tickets, the review comments, and where things had stalled. The pattern was that he was blocked in the payments codebase, which only one other person understood, and he had stopped asking. In our one-to-one I described what I had seen and asked what was going on, rather than opening with the gap. He said he had been afraid of looking slow. We set two specific expectations for the next six weeks in writing: a defined scope he owned end to end, and a standing pairing session with the engineer who knew payments. I fixed my own side too, since I had allowed a single-owner codebase to persist for a year. After each check-in I wrote notes, so the conversation stayed the same conversation, and I told him plainly what would follow if nothing changed.
Result
He met the six-week expectations and stayed on the team; a year later he was the second person who knew payments properly. I have had this go the other way as well, and the written notes mattered just as much then, because the person was never surprised by the outcome. What I changed permanently is the cadence — I now catch this pattern at the two-week mark instead of the two-month mark.

Five Mistakes I Hear Most Often

Each one is common enough that I hear it several times in a single hiring week, and each has a fix that takes one sentence to apply.

1

Three minutes of Situation

The candidate sets up the company, the team, the reorg, the quarter and the stakeholders. By the time they reach what they personally did, the interviewer has lost the thread and half the slot is gone.

Instead: Two sentences of context, then move to what you were responsible for. If I need more background I will ask for it.

2

"We" hiding what you did

An answer told entirely in the first person plural leaves me unable to score you. I have listened to five minutes about an excellent project and written nothing down, because I still could not tell which part was yours.

Instead: Use "I" for your decisions and your work, and keep "we" for the moments the team really did act as one.

3

No result at all

The story ends with the work being finished and never says what happened next. Without an outcome the answer describes activity, and activity is the cheapest thing in an interview to claim.

Instead: Close on the outcome in the terms you opened with, with a number if you honestly have one and a lesson if you do not.

4

A memorized script under a different question

Rehearsed answers survive only the question they were written for. Asked about conflict with a peer instead of a manager, the candidate recites the prepared version anyway, and the mismatch is audible in the first sentence.

Instead: Learn the stories, not the wording. If the question does not fit, say which part of your story does and reshape the rest live.

5

A story with no tension

The project that went smoothly produces an answer with nothing in it. If nothing was at risk and nobody disagreed, no judgment was required, and there is nothing on the scorecard to rate.

Instead: Choose the moment something was going wrong. Difficulty is the material the question is asking for.

Build a Story Bank Before You Need It

Good preparation gives you material rather than lines to recite: enough real stories that any STAR method interview question lands on something you actually lived through.

Six to eight stories from the last few years is the right size. Fewer and you will force a bad fit onto a question that does not want it; more and you will hesitate mid-answer while you choose. Write each one into the four boxes on a single page, with the numbers you can defend. You are building recall, not a script.

Then map them against the competencies loops actually score. Every rubric I have written, and most I have been handed, comes down to a handful of themes:

Delivery under constraint

You shipped something real against a deadline, a gap in headcount, or a system you were not allowed to rewrite.

Conflict and disagreement

You disagreed with a peer, a manager or a product owner, and the working relationship came out intact.

Failure and recovery

Something you owned went wrong. What you did in the next hour, and what you changed in the next month.

Leadership and influence

You moved a decision or a group you had no authority over, or you managed the person nobody else wanted to manage.

Ambiguity

The requirements were unclear or the problem was undefined, and you made progress before anyone handed you clarity.

Feedback and growth

You were given hard feedback and changed something real, or you gave it to someone more senior than you.

Then practice out loud

  • Say each story to an empty room with a timer running. The gap between how a story reads and how it sounds is larger than anyone expects, and the timer shows where the time goes — usually into the setup, at the expense of the Action.
  • Run mock rounds with an AI model. Paste the job description, ask it to interview you as the hiring manager for that role, then ask which competency your answer demonstrated. It will not flatter you, and it asks the follow-up questions you were hoping to avoid.
  • Do at least one round with a person who has hired for the role. AI mocks are unlimited and genuinely useful; a human catches the thing you have stopped hearing in your own answer.

Does STAR Work for "Tell Me About Yourself"?

No. It is the question people reach for first when they look up how to answer behavioral interview questions, and it is the one STAR does not fit. It asks for an arc across your career rather than a single story.

When I ask you to tell me about yourself, I am asking you to decide what matters about your own career in about ninety seconds. A STAR answer lands wrong here: forty seconds of Situation about a job you left three years ago tells me you cannot select.

Your story bank still feeds it. Take the two stories that define you, compress each to one line, and hang the middle of the answer on them. When I follow up on one, the full STAR version is already loaded.

About 20 seconds

What you do now

Role, scope, the one thing you own. That is enough for me to place you, and the history can wait.

About 40 seconds

The experience that shaped you

Two or three moves and the reason for each, with your two defining stories compressed to a line apiece.

About 20 seconds

Why this role

What you want next, and why this job is the specific answer to it. Name something real about the team.

Skeleton · backend engineer

A skeleton, not a script

I'm a backend engineer, six years in, on the payments team at a fifty-person fintech, where I own the ledger service end to end. I started in infrastructure and moved to backend because I kept ending up in the code anyway. The two I'd point to are taking checkout p95 from eleven seconds to under two, and turning payments from a one-owner codebase into something three people can ship in. I want a larger system and a team that reviews properly, which is why this role is on my list.

Frequently Asked Questions

What is the STAR method?

STAR is a four-part structure for answering behavioral interview questions: Situation, Task, Action, Result. You give the context briefly, state what you were responsible for, walk through what you personally did, and finish with how it turned out. It exists because interviewers score specific past behavior, and an unstructured answer usually leaves the specifics out.

How long should a STAR answer be?

About two minutes, weighted toward the back half: roughly fifteen seconds of Situation, fifteen of Task, sixty to ninety of Action, and thirty of Result. Answers that run long are almost always long in the setup, which is the part the interviewer needs least. If the interviewer wants more they will ask a follow-up, and leaving room for that follow-up is part of a good answer.

How many STAR stories do I need?

Six to eight stories from the last few years cover nearly every behavioral question you will be asked. Spread them across different themes — delivery, conflict, failure, leadership, ambiguity — so you are not retelling the same project three times in one loop. Most candidates who feel unprepared have plenty of experience and no index into it.

What is the difference between STAR, SOAR and CAR?

They are the same idea with different labels. SOAR uses Situation, Obstacle, Action, Result; CAR compresses it to Context, Action, Result. Any of them works, because what the interviewer scores is whether your answer names a real situation, your own actions and an outcome. Pick one and stop thinking about the acronym.

Do interviewers know when candidates use the STAR method?

Yes, and it still works. Anyone who has run a structured loop recognizes the shape within a sentence or two, and it comes as a relief, because it means the answer will contain the things that have to be scored. STAR is a clarity tool rather than a trick. What interviewers dislike is a memorized script, which is a different problem with a different fix.

Does the STAR method work for "tell me about yourself"?

Not really, because that question is not a behavioral one. It asks for a short arc in about ninety seconds: what you do now, the experience that shaped you, and why you want this role. STAR is built around one past event, so a full four-part answer spends your opening on setup. Use two of your stories as one-line references inside the arc, and keep the full version for the follow-up.

Where to Go Next

This guide is free and complete on its own. These are the next steps if you want them.

Tech Interview Coaching

Mock rounds and preparation for behavioral, system design and leadership interviews, up to VP and CTO level.

See interview coaching

AI Job Search Coaching

Running a search with AI doing the repetitive work: picking targets, tailoring applications, keeping a pipeline moving.

See job search coaching

ATS Resume Checker

Paste your resume and see what an applicant tracking system reads. Runs in your browser, nothing is uploaded.

Check my resume

Practice With Someone Who Runs the Interviews

Reading about STAR is the easy part. The gap shows up when someone asks the follow-up question you did not prepare for. In a mock round I ask those questions and then tell you exactly what I would have written on the scorecard.

See interview coaching

Every engagement starts with a free 30-minute call.

Related reading

Hiring, engineering teams, and how AI is changing both sides of the table.

All articles