Reusing one STAR story across job applications
Tailoring a CV once and reusing it is a mistake, and the guide to common CV tailoring mistakes is right about that. A STAR story is a different object: what happened is fixed, so the story is reusable — what changes per application is which one you reach for and what you lead on.
That distinction is the whole of this guide. If you have written a few good stories and are now on your eleventh application, you do not start over each time, and you do not send the same words each time either. You keep the facts and rebuild the emphasis. Below is what that means in practice, one story carried through two postings so you can see exactly what moved, and a way to tell whether the story you are missing is genuinely missing or just needs re-pointing.
Why reusing a story is honest and reusing a CV is not
The two objects fail in opposite directions. A tailored CV is an argument for one role: a selection from your history, ordered by what that posting weights first. Send it to a second posting and the argument is now addressed to the wrong reader — the mistakes guide's fix is to keep a master and derive each application from it, and nothing here disagrees with that.
A STAR story sits on the other side of that line. It is a record of one thing that happened: the situation you were in, what you were asked to do, what you did, and what came of it. Those are facts. Rewriting them for a posting would not be tailoring, it would be changing what happened, and that is the one move this whole cluster refuses. Reusing the story is therefore not a shortcut. It is the only honest option, because the alternative is a different story about the same event.
So the master/derivation idea applies here too, at a smaller grain. The story is master material. What you derive per application is the version you tell: the opening line, the beat you spend longest on, and which of the results you put first.
What is fixed, and what you are allowed to change
Split every story into two layers and keep them apart.
Fixed — the facts. Where you were and what was going wrong. What you were responsible for. The actions you personally took, in the order you took them. What resulted, including the parts that were partial or arrived late. The people and teams involved, named by role. None of this changes between applications, ever. If you find yourself wanting to change it, either the story was wrong the first time or the posting does not fit and you are reaching.
Adapted — the framing. The first sentence, which tells the reader what kind of story this is. Which action gets the most words: the same sequence of five things you did contains a process-improvement story and a stakeholder-management story, depending on which of the five you dwell on. Which result leads: most real pieces of work produce more than one outcome, and the posting decides which one goes first. Which detail you drop from the telling, and dropped is the right word — it stays in the story, it just does not make this version.
The line between the layers is a test you can run on any sentence: could a colleague who was there read this version and recognise it as accurate? Every framing choice above passes that test. Every change to the fixed layer fails it. Writing the story in the first place is where the fixed layer gets built, and it is worth building it once, completely, precisely so that you never have to touch it again.
Worked: one story, two postings
Here is one story, told in full once, and then framed twice. The facts are the same in both columns. Read the columns against each other rather than top to bottom.
The story as written. You were a senior agent on a support team at a software company. For about a quarter, customers asking about a recurring billing charge were getting different answers from different agents, and a run of those tickets had escalated to complaints. Your team lead asked you to stop the inconsistency by the end of the month, without extra headcount. You read a week of the escalated tickets and found that the inconsistency came from one place: there was no shared definition of when a refund applied, so each agent was inventing one. You drafted a one-page decision guide, took it to the finance lead to check the refund rules against what finance would actually honour, revised it with her corrections, ran it past both teams, put it into the reply-template library, and reviewed the first batch of replies written against it. Escalations on that topic stopped within the quarter, finance stopped receiving disputes raised by support, and the one-page format was adopted for the next two topics the team documented.
Posting one is a support operations lead. Its requirements lean on process improvement, documentation, and reply quality. Posting two is a customer success manager. Its requirements lean on working across teams, owning an outcome with finance and product, and customer experience. Same story, two versions:
| Beat | Version for posting one — support operations lead | Version for posting two — customer success manager | |---|---|---| | Opening line | "A quality problem that turned out to be a missing definition." | "A billing dispute that needed support and finance to agree before customers could get a straight answer." | | Situation | Customers were getting inconsistent answers on a recurring charge; escalations were rising. | Customers were getting inconsistent answers on a recurring charge and some of those became complaints; finance was seeing disputes it had not agreed to. | | Task | Stop the inconsistency by month end, with the team we had. | Get support and finance to one answer on refunds, and get that answer to customers, by month end. | | Action, dwelt on | Reading the escalated tickets and isolating the single cause; drafting the one-page guide; putting it into the template library; reviewing the first batch of replies against it. | Taking the draft to the finance lead; folding in her corrections so support would only promise what finance would honour; running the result past both teams before it went live. | | Action, kept brief | The finance check — one clause: "checked with finance". | The template-library mechanics — one clause: "made it the standard reply". | | Result, led on | The one-page format was adopted for the next two topics the team documented, and escalations on this one stopped within the quarter. | Finance stopped receiving disputes raised by support, and escalations on this topic stopped within the quarter. | | Detail dropped from this telling | That finance had been receiving disputes at all. | That the format was reused for later topics. |
Every sentence in both columns is in the story as written. Nothing was added. The two versions would be recognised by the finance lead, by the team lead who set the task, and by the agents who wrote the first replies against the guide.
What moved between the versions, and what did not
Look at what changed. The opening line names a different kind of problem in each column — a quality problem versus a coordination problem — and both descriptions are true of the same event. The action beat spends its words on different steps: version one dwells on the diagnosis and the documentation, version two on the negotiation with finance. Each version compresses the other's centrepiece to a clause rather than deleting it. The leading result is swapped. One detail is dropped from each telling and reappears in the other.
Now look at what did not change. The situation, the task's deadline and constraint, the sequence of actions, both results, and every person and team involved are identical. Neither version claims you led the finance team, owned billing, or reduced churn — none of which happened. A reader who saw both versions would not think you had told two stories; they would think you had answered two different questions with one piece of evidence, which is exactly what you did.
This is the difference between adapting a story and tailoring a CV. The CV work — deciding whether this story earns a bullet at all for a given posting, and where that bullet sits against your other evidence — is the tailoring guide's job and stays there. The story work is deciding which of its own true faces to show.
Choosing which story to reach for
Reuse has two decisions in it, and the framing above is the second one. The first is which story to open at all, and it is made against the posting, not against your favourite story.
Take the posting's requirements as a list. For each requirement, ask which story in your library contains an action that answers it — an action, not a situation. A story set in a marketing team is not evidence of marketing skill; a story in which you did a piece of marketing work is. When one story answers a requirement, mark it. When two stories answer the same requirement, note which of them answers it with the more specific action — that one goes forward, the other stays in reserve for a posting that weights something else.
Two things follow. A story can be your strongest for one posting and irrelevant for the next, and that says nothing about its quality. And the story you reach for most often is not necessarily your best one — it is the one whose actions happen to overlap the most requirements. Both are reasons to keep choosing from the list rather than from habit.
Where the story then goes — a competency question on an application form, a paragraph in a cover letter, the fact underneath a CV bullet — is a matter of the application's format, and the framing choices above apply in each of them. How you would tell it out loud in an interview is a separate skill and is not covered here.
When the library has a hole, not a duplicate
The question people actually ask is "how many stories do I need," and there is no honest number to give. Any figure would be invented, and a library of the right size for one job search is the wrong size for another. What there is instead is a test, and you run it per posting.
Lay your stories against the posting's requirement list as above. Three outcomes are possible for each requirement, and only one of them means you need to write something.
Covered. At least one story contains an action that answers it. Reach for that story and frame it as shown.
Duplicated. Two or more stories answer it, with actions of the same kind. This is not a hole. It is a sign that you have written the same strength twice, and the cheaper fix is to notice which of the two has never been the stronger candidate for any posting and stop maintaining it. A library where every story is the best answer to something is easier to choose from than a large one.
Uncovered. No story contains an action that answers it — but be careful what you count as uncovered. Before you decide, re-read the stories that are nearest and check whether the requirement is answered by an action you have been keeping brief. In the worked example, a posting that asks for "influencing decisions outside your team" is answered by the finance negotiation, which version one had compressed to a clause. That is not a hole; it is a framing you have not yet needed. A hole is a requirement that no action in any story answers, however you frame it.
Only that last case sends you back to writing. Whether the missing story exists to be written — you did the work and never recorded it — or does not exist because you have not done the work is the subject of the guide on writing a story for a requirement your CV does not cover, and it matters which, because only the first one yields a story.
Keeping the library honest as it grows
A story library only stays reusable if edits flow into it the same way they flow into a master CV: from what happens, never from what a posting wants.
When something new occurs in the work — the guide from the worked example gets adopted by a second team, say — the story's fixed layer gains a fact, and every future version can use it. When a posting wants a result you do not have, the fixed layer stays as it is, and the story is either reframed within its facts or left on the shelf. The moment a posting edits a story, that story stops being able to serve the next posting honestly, and you are back to sending a version tuned for somebody else's job.
Two habits keep this straight. Write the fixed layer once, in full, including the results that no current posting cares about — those are the ones a later posting will lead on. And keep the versions you send somewhere separate from the story itself, so that when you re-read the story you are reading the facts and not last month's framing of them.
A reuse checklist
Before you send a story with an application, check the version you are sending, not the story in general.
- Could every person who was there read this version and recognise it as accurate?
- Is the leading result one the posting actually asks about, or just the one you like best?
- Is the action you dwell on the one that answers the posting's requirement — and did the rest of the sequence survive as at least a clause?
- Is anything in this version absent from the story as written? If so, either the story is incomplete or the version is inventing.
- Did you choose this story from the requirement list, or from habit?
- For every requirement you marked uncovered, did you re-read the nearest story for a compressed action before deciding it was a hole?
A no on the first or fourth question means the version is not honest and does not go. A no on the others usually means a few minutes of reframing.
The limit of reuse
Reuse is cheap because the expensive part — establishing what actually happened, in enough detail to frame it more than one way — was done when the story was written, and it is done once. That is why the library is worth maintaining and why its stories are read back into every check HireReady24 runs: when the product compares a posting against your history, it is looking for the action in your saved stories that answers each requirement, which is the same search this guide asks you to run by hand. What it cannot do is decide that a compressed clause is the strongest evidence you hold for a requirement — that judgement takes knowing the story from the inside, and the story is yours. And it cannot write the story for a hole it finds. Where no saved story answers a requirement, it will say so and ask you what happened, and if the answer is that nothing did, the hole is real, and no framing closes it.