TL;DR — Most CVs are not weak because the person is weak. They are weak because filler phrases hide real work behind vague words. Below are eight common phrases, why each one costs you visibility, and a stronger line to use instead. At the end, I show how we built this thinking into CVSet, the CV scoring and tailoring tool I design.
I have read a lot of CVs while building CVSet. The pattern is almost always the same: a strong engineer writes "responsible for maintaining internal systems" when what they actually did was rebuild a payment integration that six teams depend on.
The facts were there. The wording buried them.
That gap is the whole reason CVSet exists. Not to invent a better candidate — to make the real one visible.
Why filler creeps in
Filler is not laziness. It comes from three habits:
- Job-description language. You copy the phrasing from the advert you originally applied to.
- Modesty. "Helped with" feels safer than "led", especially if the work was shared.
- Speed. You update your CV at 11 pm the night before a deadline.
The fix is not to exaggerate. It is to say the same thing with the specifics still attached.
The 8 phrases
1. "Responsible for…"
This describes a job title, not a contribution. Anyone in that seat was responsible for it.
❌ Responsible for the company's CI/CD pipeline.
✅ Rebuilt the CI/CD pipeline, cutting deployment time by 10%.
If you do not have a number, use scope instead: "Rebuilt the CI/CD pipeline used by four engineering teams." Scope is still evidence.
2. "Worked on…"
"Worked on" hides your role completely. Did you design it, build it, review it, or attend the meetings?
❌ Worked on a microservices migration.
✅ Migrated three monolith modules to independent .NET services.
Pick the verb that matches what you actually did. Built, designed, migrated, tested, documented — each one tells a different story, and all of them beat "worked on".
3. "Helped with…"
Shared work is normal. But "helped" makes you sound optional.
❌ Helped with the authentication rewrite.
✅ Built the token refresh and session handling for the authentication rewrite.
You are not claiming the whole project. You are naming your part of it. That is more honest, not less.
4. "Team player"
Every candidate says this. It is a claim with no evidence behind it.
❌ Strong team player with excellent collaboration skills.
✅ Ran weekly code reviews for a team of six and onboarded two junior developers.
The second line proves collaboration without using the word.
5. "Results-driven" / "Results-oriented"
If you have results, show them. If you do not, the adjective will not cover the gap.
❌ Results-driven engineer focused on delivery.
✅ Reduced average API response time from 800ms to 210ms.
The rule: replace the adjective with the result it is describing.
6. "Excellent communication skills"
A recruiter cannot verify this. They can verify what you communicated, and to whom.
❌ Excellent written and verbal communication skills.
✅ Wrote the API documentation used by three external integration partners.
Audience plus artefact beats adjective every time.
7. "Passionate about technology"
Passion is not a qualification, and this line takes space near the top of your CV where space is expensive.
❌ Passionate about clean code and emerging technologies.
✅ Maintain an open-source .NET library with 400+ downloads.
If your passion produced something, name the something. If it did not, cut the line.
8. "Various" / "Multiple" / "A range of"
These words exist to avoid listing. But the list is the valuable part.
❌ Experience with various cloud technologies.
✅ Experience with Azure App Service, Azure Functions and Azure SQL.
This one also matters for ATS keyword matching. A scanner looking for "Terraform" will never match "various infrastructure tools".
The rule underneath all eight
Every rewrite above follows the same principle:
Same facts, better visibility.
Nothing was invented. No new skill appeared. No number was guessed. The work was always there — the wording just stopped hiding it.
This is the constraint we designed CVSet around, and it is non-negotiable in the product. The AI never adds a skill, a tool, or an achievement that is not already in your CV.
How CVSet applies this
Here is the flow, and what each step is actually for.
Step 1 — Analyse
Your CV is scored across nine dimensions, including Metrics & Impact, Clarity & Brevity, ATS Keywords and Expertise Presentation. Filler phrases usually show up as a low Metrics & Impact score, because vague verbs leave nothing to measure.
You also see the CV through four perspectives: Hiring Manager, Recruiter, Human Eye, and Algorithm. The same sentence can read fine to a human and be invisible to a parser.
That split view is the honest version of the filler problem. The left column is what your wording already proves. The right column is what it does not — and neither side is a guess, both come from your own CV against that specific job.
Step 2 — Optimise
Analysis becomes suggestions. Each one names the problem and the next step, so you are never told "improve this" without being told how.
Step 3 — Tailor
Here you paste a job description, and the CV is rewritten against it across five dimensions: Skills, Keywords, Language, Prioritisation, Quality.
Crucially, you accept or reject every change individually.
You can see the mechanism in that screenshot: the original text stays visible next to the suggestion, each change shows the score impact, and "Keep as is" is a first-class option. Prioritisation changes order only — no text is touched.
Step 4 — Skill Gap Analysis
This is the part I care most about. When the job asks for something your CV genuinely does not contain, we do not write it in.
Instead, it goes to your To-Learn List, with a reason and a concrete way to close it.
A gap is not a failure. It is the next thing to build.
What we got wrong first
Two honest lessons from building this.
Overlapping dimensions destroyed trust. In an early version, both Metrics and Completeness flagged the same missing number. Users saw one problem reported twice and assumed the scoring was padded. We fixed it with a single-owner rule: each dimension owns specific properties and has a deny-list. If a dimension does not own it, it does not mention it.
Silent changes feel worse than bad changes. Anything the tool does without asking reads as untrustworthy, even when the change is good. That is why nothing is applied until you accept it, and why we surface the original text next to every suggestion.
Score ceilings had to be honest. Not every CV can reach 100 on every dimension. Showing a ceiling you cannot reach is just a different kind of filler.
Try this in ten minutes
You do not need a tool to start. Open your CV and do this:
- Search for the eight phrases above.
- For each hit, ask: what did I actually do here?
- Rewrite using a specific verb plus a number or a scope.
- If you cannot find either, ask whether the line earns its space.
That is it. No new experience required.
Key Takeaways
- Filler is a visibility problem, not a truth problem. Your work is already good enough; the wording is the bottleneck.
- Replace adjectives with the evidence they describe. "Results-driven" becomes the actual result.
- Use scope when you do not have a number. Team size, system count and user count are all real evidence.
- Never invent to fill a gap. A missing skill belongs on your learning list, not in your experience section.
- Vague words break ATS matching. "Various cloud tools" matches nothing a parser is searching for.
- Same facts, better visibility is the only safe rewrite rule.
Over to you
Which filler phrase is still hiding in your CV right now? I would guess "responsible for" — it survives longer than the others because it sounds formal.
Next post, I want to go deeper on the ATS side: what a parser actually reads, and why formatting choices like columns and photos change the outcome more than people expect.
You can try the scoring at cvset.io.
