A skills section listing technologies as bare nouns tells a reader nothing about your level or your use of them. Semantic screening reads context, so the fix is to attach each skill to evidence: what you did with it, at what scale, and how recently. A list of thirty words becomes a shorter list of ten with sentences attached, and it performs better with both machines and people.
Why the Bare List Fails
"Python, SQL, Excel, Tableau, Git" is a set of claims with no depth. Every applicant for a data role writes something similar, so the section does not differentiate. It also invites the interview question you least want, which is to be asked to demonstrate the one you listed but barely use.
Screening that reads context is looking for the relationship between a skill and an activity. Where that relationship is absent, the tool records the mention and can infer nothing about competence, which means the skill contributes far less than you intended.
The Three Signals Missing From a Bare List
- Recency, because a technology used five years ago is not a current skill
- Depth, because using a tool and administering it are different jobs
- Context, because the same tool means different things in different settings
The Rewrite Pattern
Keep a short list for scanning, then evidence the important ones in the experience section where the context already exists. The skills block becomes an index and the proof sits alongside the work.
Before
Skills: SQL, Power BI, stakeholder management, Excel, process improvement
After
Skills: SQL (daily, 4 years), Power BI (report author, 12 published dashboards), Excel including Power Query, stakeholder management at director level
Then in the experience section: "Rewrote the weekly sales reconciliation in SQL, replacing a four-hour manual Excel process with a scheduled query, and published the output as a Power BI dashboard used by six regional managers."
The second version supports the first. A reader who wants to know whether your SQL is real has an answer, and so does a tool reading for context rather than presence.
How to Decide What Stays
Cut anything you would not want to be questioned on. That single rule usually removes a third of a typical skills section, and everything it removes was working against you by diluting the rest.
- List every skill currently on your CV
- Mark each one as used weekly, used occasionally, or used once
- Delete the used-once entries unless the advert names them explicitly
- For the weekly items, find the bullet in your history that proves it
- Where no bullet proves it, write one or reconsider the claim
Levels Without Inventing a Scale
Self-assessed ratings cause more problems than they solve. A five-star graphic is unreadable to a parser and meaningless to a reader, since nobody knows what four stars means. "Advanced" and "expert" have the same problem.
Use facts instead: how long, how often, in what capacity. "Four years, daily, including writing stored procedures" communicates a level without requiring anyone to trust your self-rating.
Certifications Belong With the Body
Where a certification carries weight, write the awarding body, the exact name and the date. "AWS Certified Solutions Architect, Associate, Amazon Web Services, 2025" is verifiable. "AWS certified" is not, and an assessor cannot tell which certification you hold or whether it is current.
Sector Variations Worth Respecting
Technical and engineering readers expect a detailed skills block and will look for it. Clinical, legal and education readers expect registration details and will look for those instead. Commercial and general management roles often need no separate skills section at all, with the evidence carried entirely in the experience.
Read three adverts in your target field and see what they ask about. If every one names specific software, the block is important. If none do, the space is better spent on outcomes.
Naming Things So They Are Recognised
Tools and frameworks have official names and a collection of informal ones. Screening that reads context still works from the words on the page, so the version you choose affects whether a reader or a tool connects your experience to the requirement.
Use the Canonical Name, Then the Common One
- "Microsoft Power BI" rather than "PowerBI" or "BI tool"
- "Microsoft Dynamics 365" rather than "Dynamics" alone on first use
- "PostgreSQL" rather than "Postgres", at least once
- "Kubernetes (K8s)" where both forms are in common use in your field
- Full name before an acronym on first mention, then the acronym freely
Internal names are the worst offenders. A system your employer called Atlas means nothing outside the building. Describe what it was and name the underlying product where you can: "Atlas, the in-house case management system built on Salesforce".
The same applies to job titles. If your title was Customer Success Ninja, put the real function alongside it in brackets, because no advert and no search will ever look for the title your employer invented.
Frequently Asked Questions
How Many Skills Should I List?
Eight to twelve for a technical role, fewer elsewhere. Beyond about fifteen the section reads as padding and the strongest entries lose prominence.
Should I Include Skills From the Job Advert I Do Not Have?
No. Claiming a skill you cannot demonstrate fails at interview or, worse, in the first month of the job. Address a genuine gap in the cover letter instead.
Do Progress Bars and Star Ratings Work?
No. They convey nothing verifiable, they are usually images or shapes that carry no extractable text, and they take space that facts could use.
Where Should the Skills Section Go?
Near the top for technical roles where screening depends on it, and after experience for most other roles. Whatever position you choose, keep it consistent and easy to find.
Should I List Soft Skills?
Only where you can attach evidence, and usually the evidence belongs in the experience section instead. "Communication" as a bare word is the least informative thing on most CVs.
A Twenty-Minute Rewrite
Take your current skills section, delete everything you use rarely, and for each survivor find the line in your employment history that proves it. Where no proof exists, either write it from work you genuinely did or drop the claim. The section gets shorter, more specific and considerably harder to dismiss.
InsightCircle
