- A skill earns a place on your resume if you can defend it for three minutes in an interview.
- Specific skills belong in bullet points where they were used. General skills belong in a dedicated section, if at all.
- Match the language of the job posting — "PostgreSQL" not "Postgres", if that is what they wrote.
- The ideal skills section has between eight and fifteen entries, not thirty.
What counts as a skill?
A skill on a resume is anything you can demonstrate or defend in an interview. This is a broader category than it first appears, but it is also a narrower one than most candidates assume. It includes:
- Technologies, tools, and platforms you have used — programming languages, software, systems, frameworks.
- Methodologies and processes you can run — agile delivery, user research, financial modelling, quality assurance.
- Domain knowledge — a specific industry, regulatory area, or market.
- Languages spoken, with a level of proficiency.
- Soft skills, but only when they are distinctive and provable. "Stakeholder communication" is a skill if you have led cross-functional projects. "Team player" is not a skill.
What does not count: personality traits, generic adjectives, and any phrase that describes everyone in your field. If you are not sure whether something counts, apply the three-minute test: if a hiring manager asked you to talk about this skill for three minutes, would you have three minutes of substance to say? If yes, it counts. If you would fall back on generalities, leave it off.
Where do skills belong?
A skill belongs in one of two places on your resume.
The first is inside the bullet point that demonstrates it. If you used PostgreSQL to build a reporting pipeline, that skill belongs in the bullet that describes the pipeline, not in a floating list. Skills in context carry much more weight because the reader can see the scale, the outcome, and the role you played.
The second is a dedicated skills section, which serves a different purpose: it lets an ATS scan or a skimming reader match your capabilities against the job description. This section is a matching aid, not evidence. It should contain only skills that also appear somewhere else on your resume, in a bullet point, a project, or a course. A skills section full of entries that do not appear anywhere else suggests padding.
The exception is early-career candidates with limited experience. If you are a recent graduate, your skills section may be one of the only ways to show what you know, and it is reasonable for it to carry more of the resume's weight.
Matching the language of the job posting
ATS keyword matching works on literal strings. If the job posting says "PostgreSQL" and your resume says "Postgres", the match may fail. This is not a reason to include every possible variant, but it is a reason to use the same language the posting uses when both versions are accurate.
The rule: use the posting's term if it is correct. Do not use a term you have never used in practice. If the posting says "React.js" and you write "React" in your resume, most systems will match either, but not all. If the posting says "SDLC" and you write "software development lifecycle", the match may fail on the acronym.
Check the posting for a "nice to have" section and make sure your resume names anything from that list you actually have. This is the highest-leverage adjustment you can make to a skills section. It takes two minutes and it directly improves your match.
How many skills is too many?
Between eight and fifteen skills is the usual sweet spot. Fewer than eight, and the section does not give the reader enough to scan. More than fifteen, and the section stops functioning as a scan and starts reading as a wall — the reader stops and moves on without extracting anything.
If you have more than fifteen skills, you have three options. You can group them: "Languages: Python, Go, SQL. Tools: Kafka, Kubernetes, Terraform." You can move some of them into bullet points where they belong anyway. Or you can drop the weakest ones — the ones you would hesitate to talk about for three minutes.
For senior candidates, five to eight skills is often better than fifteen. The senior resume makes its case through the bullet points and the scope of the roles. The skills section is a small matching aid, not the main event.
Should soft skills appear on a resume?
This question comes up a lot, and the honest answer is: usually not in a dedicated section, and usually not as a bullet on their own.
Soft skills — communication, collaboration, leadership, adaptability — are almost always better demonstrated than declared. A bullet point that says "led a cross-functional team of eight to deliver a project under budget" demonstrates leadership far more convincingly than listing "Leadership" in a skills section.
There are exceptions. If you are applying for a role where a specific soft skill is central — for example, a customer success role that demands written communication, or a programme manager role that requires stakeholder management — naming the skill in a short line within a summary or a role bullet can be useful. The point is that the skill should be attached to evidence, not floating on its own.
Formatting the skills section
The skills section should be quick to scan. Two formats dominate:
Grouped list. Each group is a line. "Languages: Python, Go, SQL" on one line, "Frameworks: Django, Flask" on the next. This is the format senior engineers often use, and it reads well when the grouping is obvious.
Chip or tag list. Skills are rendered as small inline chips or separated by a middle dot. "Python · Go · SQL · Kafka · Kubernetes". This reads quickly on-screen and works well for a broad skills list.
Both formats are fine. What matters is consistency: if you group, group everything. If you chip, chip everything. Mixing the two within the same section makes the resume harder to scan.
Do not use progress bars or star ratings for skills unless you are applying to a design role where the visual is expected. Outside of design, progress bars read as arbitrary — what does 4 out of 5 Python actually mean? — and they add visual noise that a plain list would not.
Skills section checklist
- Can you defend each skill for three minutes? If not, remove it.
- Does each skill appear somewhere else on the resume? If not, add a bullet or a project that demonstrates it, or remove it.
- Is the count between eight and fifteen? If not, group, move, or cut.
- Does the list match the language of the posting? Align any terms where both versions are accurate.
- Is the format consistent? Grouped or chipped, not both.
- Are soft skills attached to evidence? If a soft skill is present, make sure a bullet elsewhere on the resume proves it.