The short answer
List hard skills only, in the exact words the posting uses, grouped so a human can scan them. Soft skills belong in your experience bullets as evidence, not in a list as claims.
What matters most
- Hard skills, tools, systems, languages and certifications belong here.
- Soft skills belong in experience bullets, demonstrated rather than asserted.
- Match the posting's exact spelling, and include the acronym and the full term where both are common.
- Do not rate yourself with stars, bars or percentages.
What counts as a skill for this purpose
A useful test: could a reasonable person disagree with you about whether you have it, and could the disagreement be settled? "Advanced Excel" can be settled — someone can ask you about index-match, pivot caches or Power Query. "Excellent communicator" cannot be settled by any question, which is why it carries no weight.
- Software and systems
- Salesforce, SAP, Epic, AutoCAD, Xero, Figma, Jira, HubSpot. Name the specific product, not the category.
- Technical methods
- Regression analysis, TIG welding, phlebotomy, financial modelling, penetration testing, HACCP.
- Languages
- Both programming languages and spoken ones. For spoken languages give a level — native, fluent, professional working proficiency, conversational.
- Certifications and licences
- CPA, RN, PMP, CDL Class A, SIA licence, CompTIA Security+. Include the awarding body and expiry if it is short-dated.
- Regulated knowledge
- GAAP, IFRS, GDPR, HIPAA, OSHA standards, IFRS 16. These are frequently the exact terms a compliance-heavy posting filters on.
The soft-skills problem
Nearly every resume lists communication, teamwork, problem-solving, leadership and attention to detail. Because nearly every resume lists them, they distinguish nobody. Worse, they occupy the part of the document a parser treats as your keyword index, diluting the terms that would actually match.
This does not mean employers do not care about them — they care enormously, which is what the interview is for. It means a list is the wrong instrument. Move each one into the experience section and turn it into an event.
Skills: Leadership, Communication, Problem-solving, Teamwork, Time management
Experience bullet: "Took over a 9-person team mid-project after the lead resigned, rebuilt the delivery plan in a week and shipped on the original date."
Attention to detail ★★★★★
Experience bullet: "Processed roughly 900 invoices a month with an exception rate under 1% across two years."
Getting the wording exactly right
This is the part with the highest return and the least effort. Applicant tracking systems match strings, and a surprising number of them still match them fairly literally. Small wording differences cost you matches for skills you genuinely have.
- Copy the posting's spelling. If it says "JavaScript", do not write "Javascript" or "JS". If it says "Microsoft Excel", "Excel" alone may still match but the full string is safer.
- Give both the acronym and the expansion the first time, where both are in common use: "Search Engine Optimisation (SEO)", "Certified Public Accountant (CPA)". Different postings use different halves, and one line covers both.
- Watch UK and US spellings. Organisation and organization, analyse and analyze, licence and license. Match the market you are applying into; if the employer is American, use American spelling throughout the document, not just here.
- Use the product name, not the category. "CRM experience" matches far fewer requisitions than "Salesforce" — and if you know two, name both.
- Do not keyword-stuff. A block of eighty comma-separated terms, or white text hidden behind the background, is detectable and gets applications binned. It also fails the human check immediately.
Our ATS checker exists mainly to do this comparison for you: paste the posting alongside your resume and it lists the terms present in one and missing from the other, so you can see which of them are true of you and add those.
How to group and order it
A flat alphabetical list of thirty items is technically complete and practically unreadable. Group by kind, with the group most relevant to the posting first, and keep each group short enough to take in at a glance.
A working example for a data role:
- Languages & querying
- SQL (PostgreSQL, BigQuery), Python (pandas, scikit-learn), R
- Visualisation
- Tableau, Power BI, Looker Studio
- Data engineering
- dbt, Airflow, Snowflake, Git
- Methods
- A/B testing, cohort analysis, time-series forecasting, regression
Four labelled lines carry more information than twenty loose ones, and the labels themselves are useful keywords. Set them in two or three columns if you are tight for space — the text order is preserved, so it does not affect parsing.
How many to list
Somewhere between eight and eighteen for most roles. Below eight looks thin unless your field genuinely runs on three tools. Above eighteen and you are almost certainly listing things you used once, which is a liability rather than an asset, because everything on the page is fair game in an interview.
Languages, and how to state a level honestly
Spoken languages are one of the few genuinely differentiating items a skills section can carry, and they are also where the most overclaiming happens — usually not deliberately, but because "conversational" means very different things to different people.
Use a recognised scale where you have one. The Common European Framework levels (A1 through C2) are widely understood in Europe and increasingly elsewhere, and they are specific in a way that self-description is not. Where a framework would look out of place, plain professional wording works: native, fluent, professional working proficiency, conversational, basic. What all of these have in common is that they are legible to someone else, unlike "good" or "intermediate".
Be conservative about the top of the scale, because a language claim is unusually likely to be tested — a bilingual interviewer switching languages mid-conversation is a normal thing that happens, and it is not intended as a trap. If your German is good enough for a meeting but not for a contract negotiation, "professional working proficiency" describes that accurately and costs you nothing.
One thing worth adding when it applies: the context in which you used it. "Spanish — C1, used daily with suppliers in Mexico for three years" is far more useful than a bare level, because it tells the reader what kind of language you actually have. Someone whose Spanish is technical and commercial and someone whose Spanish is social may sit at the same nominal level and be suited to entirely different roles.
Where to put it
Position depends on how much of your case rests on tools rather than track record.
| Your situation | Put skills | Reasoning |
|---|---|---|
| Experienced, staying in your field | Below experience | Your history is the argument; skills confirm it. |
| Technical role where the stack is the requirement | Above experience, or in a sidebar | A hiring engineer checks the stack before reading anything else. |
| Recent graduate | Above experience | You have more demonstrable skill than employment, so lead with the stronger material. |
| Career changer | Above experience, as part of a qualifications block | The relevance argument has to be made before the history is read. |
Skills that are really achievements in disguise
A recurring pattern in weak skills sections: an item that is not a tool or a method but a compressed description of something you did. "Budget management", "team leadership", "process improvement" and "stakeholder engagement" all fall into this group. They read as skills, but they are activities, and an activity without an outcome is exactly the kind of unverifiable claim the section should not contain.
The test is whether the item names something you could be examined on. Nobody can quiz you on "process improvement" in the abstract; they can only ask what you improved. So either move it into the experience section as a bullet with a result attached, or — if the posting uses that exact phrase and you want the keyword match — keep it in the skills block but make sure the corresponding evidence appears in your experience, so a reader who checks finds the substance behind it.
Handling skills you have not used recently
A genuinely common problem, and one where people tend to choose badly between two bad options: list it and hope nobody asks, or drop it and lose the match.
The third option is to date it. "Java (last used commercially 2021)" or "French — fluent, professional use through 2019" is honest, still matches, and pre-empts the awkward moment where an interviewer opens with a question you cannot answer. It also reads as confident rather than evasive, because you volunteered the limitation instead of being caught by it.
The judgement call is how far back is too far. A programming language you last wrote three years ago is recoverable in a fortnight and worth listing; one you last wrote in 2012 probably is not, because the ecosystem around it has changed more than the syntax has. For tools, the useful question is whether the version you knew still resembles the current one — someone who used Excel heavily a decade ago is still competent at Excel, whereas someone who used a specific SaaS product a decade ago may be describing an application that no longer exists in that form.
Skills you are actively rebuilding
If you are returning to work after a break, or coming back to a technology after time away, say what you are doing about it rather than leaving the reader to guess. "SQL — refreshing through a current certification, exam booked April" is a concrete statement with a date attached, and it answers the question a cautious hiring manager was going to ask silently and then act on.
The honesty line
The strongest reason to be conservative here is not ethical, it is tactical. Everything in this section is an invitation. Listing a tool you touched once means a technical interviewer may build twenty minutes of questions around it, and the failure is far more damaging than the omission would have been.
A useful standard: list it if you could do something useful with it today, without a tutorial open. If you are actively learning something and it matters for the role, say so explicitly — "Currently completing the AWS Solutions Architect Associate, exam booked for March" is credible and shows direction. "AWS" on its own, when you have watched half a course, is a trap you set for yourself.
For a sense of which skills genuinely get screened for in a specific job, each page in the examples library lists the terms that commonly appear in postings for that role, alongside a full sample resume showing the skills block in context.
Questions people actually ask
How many skills should I list on a resume?
Roughly eight to eighteen, grouped into three or four labelled categories. Fewer looks thin, and more usually means you are listing things you have barely used, which becomes a problem in the interview rather than an advantage in the screen.
Should I include soft skills?
Not as a list. Employers care about them enormously, but a claim in a list carries no weight because every competing resume makes the same claim. Demonstrate them in your experience bullets, where the reader can see the situation and the outcome.
Do skill bars and star ratings help?
No. The scale is self-assigned and undefined, so it tells a reader nothing they can compare, and it parses as noise. If you want to indicate level, write it in plain words with something concrete attached.
Where should the skills section go?
Below your experience if your track record is the main argument, above it if the tools are the requirement — which is usually the case for technical roles, recent graduates and career changers.
Should I list every version and every tool I have used?
No. Version numbers age badly and rarely matter, and a long tail of tools you touched once dilutes the terms that count. List what you could use competently today.
