Most resume skills sections fail in one of two directions. Either they list 30 tools copied from a template, or they list adjectives no parser can match. A useful section sits in the middle: a short, grouped inventory of abilities you can defend in an interview, ordered by what the posting asks for. This guide covers what to list, how to separate hard and soft skills, and what to cut before you export.
Part of the free resume builder guide. If you are rewriting the whole document, pair this with the section-by-section build walkthrough.
What belongs in a resume skills section
A skill belongs on the page if you can do three things: name it precisely, point to work where you used it, and discuss it for two minutes without notes. That test removes most filler. “Python” passes if you shipped a data pipeline. “Excel” passes if the job requires spreadsheet modeling. “Hardworking” fails because it is not a skill; it is a character claim.
Build the list from target postings, not from memory. Collect three job descriptions for the role you want, highlight repeated tools and methods, and keep the overlap first. If most postings ask for SQL and one asks for Tableau, SQL leads and Tableau follows. This is the same mirroring logic used across the ATS resume guide, applied to one section.
A skills section is an index, not an argument. The argument lives in your bullets. Listing “Kubernetes” is useful when a parser searches for it and a human sees it. Listing “Kubernetes” without a single deployment, migration, or debugging story is a liability in the interview. Keep the index honest and let the experience section carry the proof.
Hard skills versus soft skills
Hard skills are verifiable and searchable: languages, frameworks, platforms, methods, certifications, and domain knowledge. Soft skills are behavioral: communication, ownership, mentoring, prioritization. Both matter, but they do not belong in the same format. Hard skills earn a place in the list. Soft skills earn a place in a bullet that shows the behavior at work.
| Type | Examples | In the skills list? | Where to prove it |
|---|---|---|---|
| Technical | TypeScript, SQL, Figma, Docker | Yes, grouped by category | Skills line and bullets |
| Domain | GST filing, clinical coding, payroll | Yes, when the target role needs it | Experience bullets |
| Method | Agile delivery, incident response, SEO audits | Yes, with one concrete use | Project or role bullets |
| Soft | Mentoring, stakeholder management | Rarely on its own | Bullet with scope and result |
| Traits | Hardworking, team player, passionate | Never | Delete |
“Mentoring” as a lone word tells a reader nothing. “Mentored 4 junior analysts through their first quarterly close” shows the behavior, the scale, and the context. The same rule applies to communication: instead of listing it, write “presented monthly revenue findings to a 12-person leadership group.” The skill is visible without being asserted.
How many skills, and how to group them
For most non-executive resumes, 8 to 14 skills is the useful range. Fewer than eight can look thin for a technical role. More than 14 starts to read as a dump, and the reader cannot tell which items are current. Group them into three to five labeled lines so the section scans in one pass.
- Languages and frameworks: TypeScript, React, Node.js, PostgreSQL.
- Platforms and tools: AWS, Docker, GitHub Actions, Figma.
- Methods: code review, incident response, A/B testing.
- Domain: payments, subscription billing, fraud review.
Order groups by relevance to the posting, not by personal pride. A frontend role should see the UI stack first. A platform role should see infrastructure first. Keep naming consistent across the document: if the resume says Next.js in one place, do not write NextJS in another. Avoid rating bars, percentages, and star icons; they add visual noise, parse poorly, and invite arguments about what four stars mean.
Do not repeat the same skill in three groups to look comprehensive. Duplicates waste space and make the section harder to scan. One mention in the most relevant group is enough, with proof in the bullets below.
ATS keyword matching for skills
Parsers generally match literal strings, not meanings. If the posting says “JavaScript” and your resume says “JS,” some systems will treat those as different terms. Write the form the posting uses, and include the common abbreviation in parentheses when both are honest: “JavaScript (JS).” The same applies to “CI/CD,” “PostgreSQL,” and hyphenated tool names.
Frequency matters less than placement. A term that appears once in a skills line and once in a bullet is easier to trust than a term repeated six times in a comma-separated block. Use the checker to find missing terms, then decide which ones are true and relevant. The goal is coverage, not density. A resume that scores well but cannot support the claims in an interview is worse than a lower score with defensible content.
Finally, keep the skills section outside tables, columns, and text boxes. A visually tidy grid can scramble reading order or drop content entirely. Plain lines with bold group labels parse cleanly and still look organized on a one-page PDF.
What to cut, and what to rename
- Obsolete tools. A framework you last used in 2017 takes space from the stack the posting asks for now.
- Generic software. “MS Office” only helps when the role explicitly requires Excel, PowerPoint, or Word.
- Character claims. Hardworking, detail-oriented, and team player are unverifiable and ignored.
- Skill bars and percentages. They are subjective, hard to parse, and easy to mock in an interview.
- Course-only tools. Keep a tool only if you built something with it; otherwise move it to a certification line with the project named.
- Inflated languages. “Fluent” invites a conversation in that language. Use “professional working proficiency” when accurate.
- Hobbies and interests. They belong in a short extras line only when relevant or genuinely distinctive.
Rename vague labels into searchable ones. “Data visualization” becomes “Tableau, Looker Studio.” “Social media” becomes “paid social, content calendars, Meta Ads Manager.” “Project management” becomes “Jira, sprint planning, stakeholder reporting.” Specific nouns survive both the parser and the six-second human scan.
Two skills sections, rewritten
Example 1 — software developer. Before: “Skills: HTML, CSS, JavaScript, jQuery, Bootstrap, PHP, MySQL, WordPress, React, Node, Git, hardworking, team player, MS Office, good communication.”
After: “Languages: TypeScript, JavaScript, SQL. Frontend: React, Next.js, Tailwind CSS. Backend: Node.js, Express, PostgreSQL. Tools: Git, Docker, GitHub Actions.”
The before list mixes current and legacy tools, pads with traits, and gives no hierarchy. The after list is 12 items in four groups, all of which the candidate can defend. The proof sits in the bullets: “Rebuilt checkout in Next.js, cutting first-load time 38% on mobile.” The skills line makes the claim findable; the bullet makes it credible.
Example 2 — marketing generalist. Before: “SEO, SEM, social media, email marketing, communication, creativity, Microsoft Office, Google Analytics.”
After: “SEO: technical audits, keyword mapping, Search Console. Analytics: GA4, Looker Studio, UTM tracking. Lifecycle: HubSpot, email segmentation, A/B tests. Paid: Meta Ads Manager, Google Ads.”
The rewrite replaces broad labels with the actual platforms and methods a hiring manager searches for. It also creates natural interview topics. “Keyword mapping” invites a question about a specific audit; “communication” invites nothing. If the candidate has never run a technical audit, that item should come out, even if the posting mentions it. The section must survive scrutiny, not just the parser.