Here are two bullets from a manual QA engineer’s CV. Read them as a hiring manager would:
- A. “Responsible for manual regression testing of the claims module.”
- B. “Wrote a regression checklist from three months of bug reports, cutting each release’s regression testing from three days to a day and a half.”
After A, you know the writer had a job that involved regression testing. After B, you know what they did, how they did it, and what changed. You probably also have a follow-up question. That’s a good sign. A bullet that makes an interviewer curious is doing its job.
Bullet A is a duty. It describes the role and leaves out the person in it. Here’s a handy test. Ask yourself, “What would someone who was bad at this job write here?” If the answer is the same line, it’s a duty. Duties often feel modest and safe, but they tell the reader only what anyone else in the same role could also claim.
An Achievement Story, Cut to One Line
You already have the raw material. A good CV bullet is an achievement story from your story bank, cut down to one or two lines in this order:
- A verb for what you did
- What you did it to
- How you did it, with tools named where you used them
- The result
The fastest way to get there is by subtraction. Take a story bank entry and strike out the situation first, because the job title above the bullet already sets the scene. Then strike out every action except the main one. Trim the result to its core, and rebuild what’s left in verb-what-how-result order.
Say you’re a developer at a small web agency with a 150-word story about the agency’s first continuous integration pipeline. After subtraction, it becomes this:
Set up the agency’s first CI pipeline (GitHub Actions, pytest) for 12 Django client projects, catching failing deployments before they reached clients.
A recruiter’s search can find that line, and a hiring manager can ask about it. If CI is new to you, Continuous Integration and Deployment for Python With GitHub Actions shows the kind of setup that bullet describes. The remaining details are waiting in your story bank for the interview.
Four Ways Bullets Go Wrong
Duties have a few siblings. Watch for these as you write.
The word cloud. A typical new graduate’s bullet reads, “Leveraged Python, FastAPI, PostgreSQL, Docker, React, and Git in an agile team environment.” The reader sees six familiar names and learns nothing about what the writer did with any of them.
Pick the one or two tools that matter for your target role and show them doing something, like “Built the event search API for a campus events app in FastAPI and SQLite, used by 300 students in the first term.”
The rest of the tools can live in your skills section.
The paragraph. This is the opposite failure. Picture a sysadmin’s four-line bullet that starts in 2019 with the university’s decision and slowly works its way to the result. Cut it down to the action, the tool, and the result, like “Moved 300 lab machines to Ansible over 18 months, cutting new-machine setup from a day to under an hour.”
The mystery number. “Improved page load speed by 70%” sounds great until an interviewer asks, “70% of what, measured how, and what difference did it make?” A number earns its place when it has a baseline or a scale and a consequence. If you can’t explain a number, a clear qualitative result works better. For example, “still in use by the team two years later” is believable and checkable.
The wrong-sized verb. Words and phrases like “helped” or “was involved in” hide your part when you did more. Inflated verbs like “spearheaded” claim more than you did. Use “led” only when you directed other people’s work. The Muse keeps a long list of action verbs to choose from.
Take a teacher who rebuilt their department’s grade tracker alone. The right verb is “rebuilt” rather than “helped with.” If they also helped a colleague at another school set up a similar tracker, “helped” is exactly right, followed by how, like “Helped a colleague at another school set up the same tracker, adapting it to their timetable.”
There’s one more check worth doing on every line. Read only its first five words aloud, the way a skimmer does. “Was responsible for the…” says nothing. “Automated weekly route reports in Python…” says most of it.
Tools in Context
Remember how the recruiter’s search for “Excel” missed the teacher’s bullets in the last lesson? Here’s a grade tracker story after subtraction:
Rebuilt the department’s grade tracker in Excel after finding that two teachers’ formulas disagreed, so the whole department worked from one consistent set of results.
The tool appears where the writer used it, and the verb matches what they did. A skills line that says “Excel” still helps recruiters find you, but every tool that matters for your target role should also appear in a bullet doing real work.
If a bullet needs a fact you don’t have, such as how many classes the tracker covered, don’t guess. Write a question mark and find out. Every number on your CV is one an interviewer might ask about.
Write Your Own Bullets
Time to turn your story bank into bullets. Grab a pen and paper for the first one, because striking things out is easier on paper:
- Pick your two strongest story bank entries for your target role.
- Strike out the situation, then every action except the main one.
- Rebuild each in verb-what-how-result order, using one or two lines.
- Run the first-five-words test and the “could you defend it in an interview?” test.
- Save them in
cv/bullets.mdin your career folder, grouped by job or project, with a note identifying the source story for each bullet.
Then do the same for the other stories you’d use for your main target role. Bullets from a previous career count too, written in your target role’s vocabulary with the help of your translation table.
Up next, you’ll take your bullets into a workshop with Mentor AI and practice the whole process, first on someone else’s CV and then on your own.
