Technical Skills
A technical skills section is the most searched part of a resume and the most often wasted. A forty-item comma-separated list matches everything and communicates nothing, because a reader cannot tell which four of the forty you actually use.
The fix is structural rather than editorial: group them, order them by how central each is to your work, and cut anything you would not want to be questioned about.
Group, do not list
Three to five labelled groups of four to eight items each is read. One long line is skimmed, and the items in the middle of it are effectively invisible.
The labels should reflect how the field thinks about the work — "Languages", "Databases", "Cloud and infrastructure", "Testing" for a developer; "Imaging", "Laboratory", "EHR systems", "Regulatory" for a clinical role.
Within each group, order by how much you actually use the item. Readers assume the first is the strongest, and the assumption is usually right, which makes ordering a free way to communicate level.
What to include and what to cut
The right-hand column is what makes a section long without making it stronger. Every item there dilutes the ones that matter, and a reader scanning for the four things they care about has to work harder to find them.
| Include | Cut |
|---|---|
| Tools you use weekly | Anything you touched once, years ago |
| Systems named in the posting, if honest | Basic office software, unless the posting names it |
| Languages and frameworks you could be tested on | Frameworks you read a tutorial about |
| Certifications, in official form | Course names with no credential |
| Domain-specific techniques | Operating systems, unless administering them |
| Regulatory frameworks you worked under | Buzzwords with no product behind them |
Representing level honestly
The problem with any single list is that it flattens a genuine difference between something you use daily and something you have configured twice. Readers know this, which is why a long list is discounted rather than believed.
Two approaches work. Split into "Proficient" and "Familiar" groups, which is honest and immediately legible. Or attach usage to the entries that matter: "Python — primary language, 5 years, including pandas and pytest".
What does not work is a rating out of five or a progress bar. They are unverifiable, they mean different things to different readers, and the question "compared with whom?" has no good answer.
Evidence the important ones in the bullets
A skill named in the skills section and never mentioned again is an assertion. The same skill appearing inside a bullet describing what you built with it is evidence, and it matches the same search.
So the strongest two or three technical skills should appear in both places: listed in the section for searchability, and shown in a bullet for credibility. "Rebuilt the nightly ETL in Airflow, cutting runtime from 4.5 hours to 40 minutes" does more for your Airflow claim than the word ever will.
This also resolves the length problem. Once the key skills are evidenced in bullets, the section can be shorter without losing anything, because it is no longer carrying the whole argument.
Currency, and old technology
- Say when, for anything not current — a skill last used in 2016 is a different claim from one used last month.
- Keep legacy technology where the role touches it; a great deal of production software is older than the people maintaining it.
- Drop versions unless the version genuinely matters, which is rare outside regulated or embedded work.
- Prefer the current official name of a renamed product, with the old name in brackets once.
- Remove anything the field has genuinely abandoned, which reads as not having kept up rather than as breadth.
When the section should be somewhere else
For technical roles, the skills section belongs high on the first page — frequently directly under the summary — because it is what a technical screener looks for first, and because they are frequently reading on a phone where the second half of page one is already a scroll away.
For roles where technical ability is supporting rather than central, it belongs below experience. Putting it at the top there signals a misreading of what the job weights.
And for a role with a single dominant required system, the honest move is to put that system in the summary line rather than relying on the reader reaching a list further down. The top of the page is where attention is, and it should hold whatever the posting most cares about.
One caveat on ordering by centrality: a skill you use constantly but would not want to keep doing should not lead the list. A resume is an argument for the next job rather than a description of the last one, and putting the thing you are trying to move away from first is how people get hired to do it again.
Frequently asked questions
Three to five labelled groups of four to eight items, ordered within each group by how much you actually use them. One long comma-separated line gets skimmed and the middle of it is invisible.
No. Every weak item dilutes the strong ones and makes a reader work harder to find what matters. A useful filter: list only what you could be questioned about in an interview without discomfort.
Split into "Proficient" and "Familiar", or attach usage to the ones that matter — "Python — primary language, 5 years". Avoid ratings out of five and progress bars; they are unverifiable and invite a question you cannot answer.
High — often directly under the summary — for technical roles, where a screener looks for it first. Below experience where technical ability supports the job rather than being the job.