Name the system, not the category
"Microsoft Office" has been assumed for fifteen years and listing it now reads as padding. "Excel — Power Query, pivot tables, index-match, VBA macros for the monthly close" describes a person who can do something. Same underlying skill, different amount of information.
This generalises. "Databases" says nothing; "PostgreSQL, query optimisation, partitioning on 200m-row tables" says a great deal. "CRM experience" says nothing; "Salesforce — custom objects, flow automation, admin certified" says what you would actually be doing. The rule is to write the term someone hiring for the role would search for, which is almost always the product name and the specific capability, not the category above it.
The category is only right when the category is the skill — "cloud infrastructure" is a real competency when it is followed by which clouds and what you ran on them.
Stating depth without a rating bar
The reason people reach for five-dot meters is a real problem: "Python" flattens the difference between a semester of coursework and eight years of production work. The meter is the wrong solution, because the scale is undefined and self-assigned. Two things work better.
Group by depth. A skills section split into "Daily" and "Working knowledge" — or "Core" and "Familiar" — conveys the same gradient in words the reader can interpret, and it is honest about where the boundary is.
Or let the experience section do it. If Python appears in two job bullets doing real work, no reader needs a rating; if it appears only in the list, they will assume the coursework level, which is usually correct. Depth demonstrated is always more credible than depth asserted.
- Group into two or three tiers rather than rating each item.
- State versions and scale where they change the meaning: "React 18", "Kubernetes across 40 services".
- Put the skills you would want to be interviewed on first — order is read as priority.
- If a skill appears nowhere in your experience, expect to be asked why.
What to leave off
Anything universal, anything obsolete, and anything you could not survive ten minutes of questioning on.
- "Microsoft Office", "email", "internet research", "typing" — assumed, and listing them signals a thin section rather than a broad one.
- Technologies you touched once in a bootcamp exercise. The interview will find them.
- Long-dead versions, unless the job is maintaining them — in which case say so, because COBOL and AS/400 experience is valuable precisely where it is wanted.
- Rating bars, star ratings and percentage meters, for the reasons above.
- Certifications inside the skills list. Those are credentials and they earn their own section, with issuer and date.
Non-technical roles with technical requirements
This is where naming specifics pays best, because the competition is not doing it. An administrative role that lists "Concur, Coupa, Workday, Navan, Google Workspace admin" beats one that lists "proficient with computers" by a wide margin, and both people may be equally capable — one of them just made it checkable.
The same applies to nursing ("Epic, Cerner, Meditech"), teaching ("Canvas, PowerSchool, Google Classroom"), warehouse work ("SAP EWM, RF scanners, Manhattan WMS") and finance ("NetSuite, Blackline, Hyperion"). Every field has a small set of systems the job actually runs on. Those names are the highest-value words in your skills section, and they are the ones a search over a database of applicants is most likely to be run against.
