How to write a STAR story from your own experience

You've been told to answer in STAR format. You know what the letters stand for — Situation, Task, Action, Result — and none of that helps, because the acronym describes a finished story and you are staring at your own history with no idea which part of it is a "situation". That is the gap this guide closes. It doesn't explain the method; it takes one real, ordinary piece of work and builds the story out of it in front of you, so you can do the same with yours.

Two things this guide is not. It is not about the CV document — a STAR story is a separate object, longer than any bullet and written for a different reader, and turning it back into a CV line is tailoring a CV to a job description, which has its own guide. And it is not about saying the story out loud. Writing a story down and performing it are different skills; this is the first one only.

We'll also stay with an ordinary case on purpose. If your material is the eighteen-month project four people owned that half-failed, the shape resists you for reasons this page doesn't cover, and the messy-project guide in this series is where that problem lives. Learn the shape on something plain first.

Start from one line on your CV, not from the acronym

The reliable way to find a story is to work backwards from something you already wrote down. Open your CV and pick a bullet that describes work you actually did, from start to finish, where you can remember what happened. Not the most impressive line — the one you can recall in detail.

Here is the one we'll use. The candidate and the work are a specimen: invented for this guide, assembled from the kind of duty that appears on thousands of real CVs, and belonging to nobody. Everything attributed to the candidate is stated here before it is used, because the entire point of a STAR story is that nothing in it is invented, and a guide that smuggled a fact in halfway through would be teaching the opposite of what it says.

Handled supplier invoice queries for the finance team.

That is a true line, and a useless one. It names a duty and nothing else. The candidate was an accounts-payable administrator at a mid-sized distribution company. What they remember is this: the monthly close kept slipping because supplier invoices arrived without purchase-order numbers and had to be sent back; the finance lead asked them to reduce the back-and-forth; they went through a month of rejected invoices, found that most came from a handful of suppliers, wrote a one-page guide with a marked-up sample invoice, rang each supplier's billing contact to walk them through it, and set up a rule on the shared inbox that flagged anything arriving without a PO reference; the next two closes went through without the finance lead having to chase them, and procurement later folded the one-pager into how they onboard new suppliers.

That paragraph is the raw material. It is already a story; it just hasn't been sorted yet. The four beats are how you sort it.

Situation: the smallest amount of context that makes the problem visible

The situation is not "where I worked". It is the specific state of affairs that made the work necessary — described in just enough detail that a stranger understands why anyone had to act.

Sort the raw material and this is what belongs here:

Month-end close in the finance team kept running late because supplier invoices were arriving without purchase-order numbers. Each one had to be sent back and resubmitted, and the same problem repeated every month.

Notice what was left out: the size of the company, the candidate's job title, how long they had been there. None of that changes whether the reader understands the problem. The test for a situation is whether cutting a sentence makes the task that follows harder to understand. If it doesn't, cut it. Most first drafts spend half their length here, and a later section is about why that is a mistake.

Task: what was asked of you — separate from the situation

The task is the part people either skip or merge into the situation, and keeping it separate is what makes the story yours rather than the team's. The situation is what was wrong; the task is what you specifically were responsible for doing about it.

The finance lead asked me to cut down the back-and-forth with suppliers so that close stopped slipping. There was no budget for new software and it sat alongside my normal workload.

Two things earn their place here. The first is who set the task and what they actually asked for — "reduce the back-and-forth", not "fix month-end", which was never within an administrator's gift. The second is the constraint: no budget, done alongside the day job. Constraints are what make an action look like a decision instead of an obvious next step, and they are the detail most often lost between the memory and the page.

If you cannot say who asked you or what exactly they wanted, that is worth noticing rather than papering over. Sometimes the honest answer is "nobody asked; I saw it and decided to" — which is a perfectly good task, and a different story from the one where you were assigned it.

Action: what you did, in the first person, in order

This is the beat that carries the weight, and the only one where length is a virtue. Write what you did as a sequence of decisions, in the order you made them, using "I".

I went through a month of rejected invoices and logged why each one had bounced. Most of them came from a small number of suppliers who were sending invoices from a system that had no field for our PO reference. Rather than keep rejecting them, I wrote a one-page guide with a marked-up sample invoice showing where the reference had to go, and rang the billing contact at each of those suppliers to walk them through it. Then I set up a rule on the shared finance inbox that flagged any incoming invoice with no PO reference, so the ones that still slipped through were caught the day they arrived instead of at close.

Read that against the raw paragraph and every step is there — but now each one is a choice with a reason. "Rather than keep rejecting them" is the sentence that turns a list of chores into judgement. Look for that moment in your own material: the point where you could have done the default thing and did something else instead. If your action section has no such moment, either you haven't found it yet or you have picked a piece of work where there wasn't one, and the second is a reason to pick a different bullet, not to invent a fork in the road.

Keep it to what you did. Where a colleague did part of it, say so in a clause and move on — "with the procurement assistant checking the supplier list" — rather than either absorbing their work into "I" or dropping it and leaving a gap the reader can feel.

Result: what was different afterwards

The result is the state of affairs after your action, compared with the situation before it. It is not a summary of the action and it is not a compliment you received.

The next two month-end closes went through without the finance lead having to chase supplier resubmissions, and procurement took the one-page guide and made it part of how they onboard new suppliers.

That is a complete result, and it contains no number. Which brings us to the question nearly everyone asks at this point.

When the result isn't a number

Advice about STAR stories usually shows a result like "cut processing time by half", and then tells you to find your own version. Most work does not produce one. Administration, support, care, teaching, coordination and most operational jobs generate very few figures on their own, and the reader in those roles is left either inventing a percentage or concluding they have no result at all.

You have a result. It just takes one of these shapes instead of a number:

• Something stopped happening. The problem the situation described no longer occurred, or occurred less. "Close stopped slipping" is a result. So is "the same question stopped coming in."
• Somebody else adopted it. Procurement taking the one-pager is the strongest line in the specimen result, because adoption is a judgement made by someone with no reason to flatter you.
• Something outlasted you. A checklist still in use, a process that survived your leaving, a document that got handed to your replacement.
• The person who set the task said it was done. Only if they did, and only in their terms — "the finance lead signed it off" is evidence; "everyone was delighted" is not.

Where you do have a number, use it, and count conservatively enough that you could be asked about it. Where you don't, do not manufacture one. A result you cannot stand behind is worse than a plain one, because the plain one survives a follow-up question and the manufactured one doesn't. And nothing here quotes a figure for what a quantified result does to your chances — we don't have a defensible one, so we aren't going to invent it either.

Two ways a true story goes wrong

Both of these happen to honest people with real material. Neither involves lying. They are worth naming because they are the two most common shapes a first draft takes.

The story that is all situation. The writer spends three paragraphs on the company, the team, the history of the problem and the politics around it, then covers what they did in a sentence. It usually comes from a good instinct — wanting the reader to understand — but the effect is that the one part of the story that belongs to the writer gets the least space. The fix is mechanical: count the sentences in each beat. If the situation has more than the action, move or cut until it doesn't. In the specimen, the situation is two sentences and the action is five, and that ratio is about right for most stories.

The story whose result is somebody else's. The writer describes what they did accurately, then reports as the result something their action didn't cause — the team hit its target, the project launched, the company grew. The result was real; it just wasn't theirs to claim. The test is a straight line: can you draw one from your action to that outcome without passing through someone else's decision? The specimen candidate could honestly say close stopped slipping because of the supplier work. They could not say "the finance team's audit went cleanly that year", even if it did, because a dozen other things stood between their one-pager and that outcome. Claim the link you can draw, state the bigger outcome as context if you must, and keep the two visibly apart.

The whole story, read once end to end

Assembled, without the labels, this is what the candidate now has:

Month-end close in the finance team kept running late because supplier invoices were arriving without purchase-order numbers. Each one had to be sent back and resubmitted, and the same problem repeated every month. The finance lead asked me to cut down the back-and-forth with suppliers so that close stopped slipping — with no budget for new software, alongside my normal workload. I went through a month of rejected invoices and logged why each one had bounced; most came from a small number of suppliers whose system had no field for our PO reference. Rather than keep rejecting them, I wrote a one-page guide with a marked-up sample invoice, rang the billing contact at each of those suppliers to walk them through it, and set up a rule on the shared inbox that flagged anything arriving without a reference so it was caught the day it came in. The next two closes went through without anyone chasing resubmissions, and procurement made the one-pager part of how they onboard new suppliers.

Every fact in it appeared in the raw paragraph near the top of this guide. Nothing was added on the way through — the beats reordered and trimmed it, and that is all they are supposed to do.

Back to the CV line

The story is the asset. But the exercise also hands you something smaller: a better version of the bullet you started from, because you now know which part of the work mattered.

• Before: "Handled supplier invoice queries for the finance team."
• After: "Stopped month-end close slipping by fixing supplier invoice errors at source — wrote the supplier guide procurement now uses for onboarding."

The second line is not the story compressed; it is the result and the most decisive action, chosen because those are the parts a reader scanning a CV needs. Which version of that line belongs on which application, and where it sits on the page, is a tailoring decision and lives in the CV guides, not here. The story stays as it is regardless — what happened is fixed — and that permanence is precisely what makes it worth writing once, properly.

A short check before you keep it

Read the finished story against these, and be strict about the second and fourth:

• The situation could not lose a sentence without making the task harder to understand.
• The task says who asked, what for, and under what constraint — or says plainly that nobody asked.
• The action is in the first person, in order, and contains at least one point where you chose.
• The action has more sentences than the situation.
• The result describes the state afterwards, not the effort, and every claim in it traces back to your own action.
• No figure appears that you couldn't defend if asked how you know it.

If you got here and the story still won't come — the bullet you chose turns out to be a duty with no decision in it, or the work is real but the result is buried under a dozen other people's — that is not a failure of the method. It is the method telling you to pick a different line, or that this piece of your history is one of the harder cases. HireReady24's stories tool does the sorting described above from your own words: you describe what happened, and it builds the beats from that, inventing nothing. What it cannot do is remember for you. The raw paragraph at the top of this guide — the part where the candidate recalled what actually happened — is the one step no tool can take, and it is the step this whole guide is really about.