The STAR method, with examples you can copy

Situation, Task, Action, Result — the structure recruiters are trained to listen for in behavioural questions, and three worked examples of it.

4 min read

Behavioural questions all sound the same once you notice the pattern. Tell me about a time you disagreed with a colleague. Describe a deadline you nearly missed. Give me an example of a decision you made without enough information. They are asking for a story, and there is a structure they are trained to listen for.

It is called STAR: Situation, Task, Action, Result. It is not a trick. It is a way of not leaving out the part that matters.

What each letter is for

Situation — the context, in one or two sentences. Where, when, who was involved. Enough that the story makes sense and no more. This is the part candidates overrun; it feels like the story, but it is the setup.

Task — what you were responsible for. This is the letter people skip, and skipping it is why so many answers are unconvincing: without it the panel cannot tell whether you led the work or watched it.

Action — what you actually did. The longest part. First person, singular: I decided, I wrote, I asked. Teams do not interview; you do.

Result — how it ended, with a number wherever you have one. Time saved, error rate, revenue, people affected, marks. If the result was bad, say so and say what you learned — a story with an honest bad ending beats a vague good one.

Rough proportions: one part situation, one part task, four parts action, two parts result.

Example 1: a disagreement

Situation. In my final-year project, four of us were building a booking app, and two weeks before the deadline the other three wanted to add a payment feature.

Task. I was responsible for the back end, so whatever we added was mine to deliver on time.

Action. Rather than argue about it in the group chat, I costed it — I wrote down the endpoints, the testing and the gateway integration, and it came to about nine days of my time against eleven days left. I brought that to the group and proposed we ship the booking flow properly and demo payments as a mock-up. I offered to build the mock-up myself that weekend so nobody felt we had dropped their idea.

Result. We submitted on time with a working booking flow and got the highest mark in our cohort. The mock-up took four hours, not nine days, and it is what the examiners asked most of their questions about.

Example 2: a failure

Situation. During my internship I was given the weekly sales report to automate.

Task. Produce the same figures the manual process produced, every Monday morning.

Action. I built it in three days and it worked on my test data. I did not check it against a real historical week before switching it on, because I was confident and I wanted to show progress quickly. The first live run double-counted refunds and overstated the week by about eight percent, and my supervisor found it, not me.

Result. We corrected it the same morning and no decision was made on the bad number, but I had to explain to the team why the figure they had seen was wrong. Since then I do not release anything that produces numbers without reconciling it against a known period first. On the next two things I automated I found errors that way before anyone else saw them.

Example 3: no experience yet

You do not need a job for this. Coursework, a club, a family business, a volunteer role — the structure is what is being assessed, not the prestige of the setting.

Situation. I ran the schedule for our university robotics club, about twenty members across three sub-teams.

Task. Get everyone to the regional competition with a working robot, on a budget of 900 dinars.

Action. I found that attendance was the real problem, not money — people were showing up for sessions where their part was not yet ready. I split the build into a dependency order, published who was blocked on whom each week, and moved two sessions to the weekend so the mechanical team could finish first.

Result. We finished the robot four days before the competition instead of the night before, and placed second. Attendance went from around half to about eighty percent once people could see when they were actually needed.

Preparing your own

Write out four stories, not twenty: one disagreement, one failure, one thing you led, one thing you fixed. Most behavioural questions are one of those four wearing a different hat, and four stories you can tell well beat twenty you half-remember.

Then say them out loud and time them. Two minutes is right; four is too long, and you will not notice you are at four. Talk2Hire scores each answer against the question that was asked and gives you the transcript, which is the fastest way to see that you spent ninety seconds on Situation and eleven on Result.

Next: the ten questions these show up in.

Reading about it is not practising it.

Take a real interview — an AI interviewer that asks follow-up questions, or a live session with a working recruiter. Every session ends with a recording and a scored report.