Here’s a typical first draft about the biggest project from two years at a small web agency:
The agency had about forty client sites, most built in PHP years ago by developers who had left. Clients kept asking for changes, and every change broke something because there were no tests and the code was hard to follow. The owners decided to move new work to Python and Django. I worked on the migration, and it went well.
Read it as a hiring manager. What do you now know about how this developer works? You know a lot about the agency and almost nothing about the person who wrote it. The draft spends three of its four sentences on background, gives one vague action, and ends with a result that’s really an opinion. Whoops!
In this lesson, you’ll turn lines from your inventory into achievement stories, which are specific episodes that show what you did and what changed because of it. These stories are the raw material for everything that follows. CV bullets, profile entries, project write-ups, and interview answers are all the same story, cut to different lengths.
Four Boxes With a Budget
You may know the STAR structure, which stands for situation, task, action, and result. The UK National Careers Service has a short guide to the STAR method with worked examples. The trick is the budget. Picture four boxes sized by how much of the story each one gets:
- Situation and task: a sentence or two together
- Actions: the biggest box, more than half the story
- Result: one sentence that closes it
The agency draft spent almost everything on the situation. To fix it, zoom in. An inventory line like “moved client projects to Django” summarizes months of work, so look for one moment within it, like a decision, a deadline, or something that broke.
What did you do first, and what did you decide? Then cut the background to a single sentence.
The same approach works outside tech. A teacher with an inventory line like “built the department’s grade spreadsheets” might focus on the week they found that two teachers’ formulas disagreed and rebuilt the tracker so the mismatch couldn’t happen again. That’s a story.
Hunt for Your Verbs
Here’s a draft from a QA engineer:
We were releasing every two weeks, and regression testing took three days. We introduced a checklist and a shared test plan, and we cut regression testing to a day and a half.
Which of those actions did the writer take? There’s no way to tell. Underline every verb in the actions box and note who performed each action. “We introduced” hides the writer’s contribution, and an interviewer will ask about it. Maybe the writer built the checklist from three months of bug reports and ran the first two cycles with it. If so, that’s what the story should say.
“We” is fine for the setting, as in “our team of four owned billing.” Each action, though, should be something you did, decided, built, or said. Naming your own part takes no credit away from anyone else. It just gives the reader the facts.
Find a Result You Can Defend
Here’s how a new graduate’s story about a logistics internship ends with “I wrote a Python script that pulled the route data and produced the weekly report as a spreadsheet.” The story ends where the work did.
So climb the “so what?” ladder. The report was a spreadsheet, so what? So the dispatcher didn’t build it by hand. So what? So it took minutes instead of most of a Monday morning, and the team kept using it after the internship ended.
Numbers help a reader judge scale, but only if they’re accurate and you can explain them. For every figure, also ask yourself “How do you know?” The graduate knows the dispatcher spent about three hours every Monday because the dispatcher said so. That’s a defensible estimate with a source. “Improved efficiency by 37%” isn’t, and it falls apart the moment an interviewer asks how it was measured.
When there’s no measurement, you still have options:
- Before and after: “regression testing went from three days to a day and a half”
- Scale: “for a department teaching about 150 students a year”
- Adoption: “the checklist is still used two years later”
A result without a number is still a result. Keep your contribution separate from the team’s outcome, too. If your automation was one part of a department-wide saving, say what your part enabled.
Small Stories Count
You might think your stories aren’t impressive enough. That feeling is so common that it gets its own discussion in Building a Healthy Developer Mindset While Learning Python. Most of a team’s work involves solving small problems well, and that’s exactly what a hiring manager wants to see you do. A regression checklist, a bug noticed across three customer reports, or two new testers onboarded can each be a strong story.
Use your requirements map to choose which stories to write first. The stories you’re proudest of aren’t always the most useful ones. For a teacher moving into data analysis, a teaching award is a lovely story, but it proves little about their skills for the new role. A rebuilt grade tracker demonstrates data cleaning and spreadsheet skills, and a presentation of exam results to the school’s governors shows an ability to explain findings to nontechnical people. So those two come first.
Try It: Start Your Story Bank
Create story_bank.md in your career folder. Look at the top rows of your requirements map, find the inventory line that best demonstrates how you meet the requirement in the top row, and write it up in this format:
## Rebuilt the grade tracker
Story: <80-150 words, situation and task briefly, your actions, the result>
Proves: cleaning messy data, spreadsheets
Result source: <how you know>
Proof: <a link, a document, or a person who'd confirm it>
If you don’t know the result yet, write “result: number to find” and come back to it. Never fill a gap with a guess you can’t explain. Then mark the inventory line with a star so you can watch your bank grow out of your list.
Up next, you’ll take your first stories into a coaching session, where Mentor AI asks the follow-up questions an interviewer would.
