STAR method examples

Examples by job, the common interview questions, and how to build your own

The STAR method is the most reliable way to talk about your work in interviews, self-evaluations and promotion packets. It forces you to land on the result, which is the part people actually weigh.

The four parts

• Situation: the context. What was going on?
• Task: what you were responsible for.
• Action: what you specifically did.
• Result: the outcome, ideally measurable.

Aim for about two minutes. Spend a sentence or two on Situation and Task, most of your time on Action, and finish clearly on the Result. If the interviewer wants more context, they'll ask.

STAR method examples by job

Software engineer: a technical problem

Situation: Sessions were failing under load and support tickets were climbing. Task: I owned the auth service. Action: I designed and shipped token rotation with a fallback for older sessions, and tested the migration on staging before touching production. Result: The failures stopped, the support backlog cleared within two weeks, and the mobile team shipped on schedule.

Customer service: a difficult customer

Situation: A long-standing customer called to cancel after a billing error charged them twice. Task: I was the agent on the call, and the account was worth about $20,000 a year. Action: I apologized, refunded the duplicate charge while they were on the line, and found the bug in our billing rule so it couldn't happen to anyone else. I called them back the next day to confirm it had cleared. Result: They stayed, renewed for two years, and wrote to my manager to thank me.

Nurse: a high-pressure moment

Situation: On a night shift, a new admission was prescribed a medication that interacted dangerously with one they already took. Task: As the nurse giving the first dose, it was my job to check. Action: I held the dose, called the on-call physician and the pharmacist, and documented the interaction. Afterwards I worked with pharmacy to add the check to our order set. Result: The patient was switched to a safe alternative, and the check now runs automatically for every patient on the unit.

Manager: resolving a conflict

Situation: Two senior engineers on my team disagreed about the architecture for a new service, and the work had stalled for two weeks. Task: I needed a decision without losing either of them. Action: I asked each to write a one-page proposal with the risks of their own approach, then ran a session where they reviewed each other's. I made the call, explained why in writing, and gave the other engineer ownership of the piece they cared most about. Result: We shipped on time, both stayed on the project, and the written trade-offs became how the team makes design decisions.

Sales: missing a target, then recovering

Situation: Halfway through the year I was at 40% of quota after two large deals slipped. Task: I needed to rebuild my pipeline without discounting heavily. Action: I went back to every customer who had said 'not now' in the previous year, offered a short paid pilot instead of a full contract, and asked each happy customer for one introduction. Result: I finished the year at 112% of quota, and the pilot offer became a standard option for the whole team.

Project manager: a tight deadline

Situation: A regulatory change moved our launch date forward by six weeks. Task: I owned the delivery plan across three teams. Action: I cut the scope to what the regulation required, moved two people onto the critical path, and set up a fifteen-minute daily check-in until launch. Result: We launched three days before the deadline, and the deferred features shipped the following month.

Designer: changing someone's mind

Situation: Leadership wanted to add a mandatory tutorial to onboarding. Task: I believed it would hurt activation, and I needed evidence, not opinion. Action: I ran five usability sessions with both versions and shared the recordings. Result: We dropped the tutorial in favor of hints shown when a feature is first used, and activation improved.

Common STAR interview questions

Behavioral interviews mostly ask variations of the same few things. Have a story ready for each:

• Teamwork: "Tell me about a time you worked with someone difficult." "Describe a time you helped a colleague succeed."
• Conflict: "Tell me about a disagreement with your manager or a colleague, and how you handled it."
• Failure: "Tell me about a mistake you made." "Describe a time a project didn't go to plan."
• Leadership: "Tell me about a time you led without formal authority."
• Pressure: "Describe a time you had to deliver under a tight deadline."
• Customers: "Tell me about a time you went out of your way for a customer."
• Initiative: "Tell me about something you improved that nobody asked you to."
• Influence: "Describe a time you changed someone's mind."

Some companies, Amazon most famously, build every interview question around a published set of principles. If yours does, map each of your stories to one or two of them before the interview.

Where STAR answers fall apart

• Saying "we" the whole time. The interviewer is hiring you, not your old team. "We shipped it" hides whether you led it or watched it.
• Spending it all on Situation. Two sentences of context, maximum. The Action and Result are what get scored.
• No result. If the story ends at "so I built it," it isn't a story yet. Even "the failures stopped" or "we hit the date" counts. Say what changed.
• A failure story with no lesson. For mistakes, the Result should include what you learned and what you do differently now.

Six stories cover almost every question

You don't need a story per question. You need six to eight strong ones that each prove two or three competencies. The same project rescue can answer "tell me about a conflict," "a tight deadline" and "influencing without authority," depending on which part you lead with. Prepare the stories, not the questions. For senior roles, add one beat after the Result: what you'd do differently. It shows you took something from the experience, and that's much of what a senior interview is listening for.

If you're not sure which six, start with these:

• The piece of work you're proudest of this year
• A time something went wrong and you put it right
• A disagreement you settled, with a colleague, a customer or your manager
• Someone you helped get better at their job
• A deadline you made that looked impossible
• Something you improved that nobody asked you to

Write each one as four lines, one per letter, before you polish anything. Then check every question in the list above has at least one story that answers it.

Using STAR on your resume

A resume bullet is a STAR story with the Situation cut: lead with the Action and end on the Result. "Redesigned onboarding after usability testing, raising activation by 12%" is a STAR story in one line. Your accomplishments make the best raw material.

Keep a library of stories

The trouble with STAR is remembering the details months later. Nisshi keeps a running record of your work and turns real moments into STAR stories you can save: a library to pull from for any interview, review or 1:1, kept privately on your Mac. If you work with an assistant like Claude, it can log the raw material for you while you work. It's yours, not your employer's, so it comes with you to the next job, which is exactly when you'll need it.

Questions people ask

Download Nisshi on the Mac App Store →