To list skills on a resume, put hard skills (tools, languages, methods, certifications) in a short, grouped list that mirrors the exact terms in the job description, and prove your soft skills inside your experience bullets instead of naming them. Keep the section to the skills the role actually asks for, drop anything assumed or generic like "Microsoft Word" or "team player," and make sure every skill you claim shows up as evidence somewhere else on the resume.
The mindset
Your skills section is a targeting layer, not a brag list
Most people treat the skills section as a place to prove they are well-rounded. They dump thirty words into it: languages, tools, adjectives, a few things they used once in 2019. The result is a block that says everything and therefore signals nothing. A recruiter skims it, learns nothing new, and moves on. An applicant tracking system reads it looking for specific terms and, buried in the noise, often misses them.
The better model is narrow and deliberate. The skills section exists to do one job: line up the words on your resume with the words in the job description, so both the software and the human can confirm in seconds that you have the specific things this role needs. It is a targeting layer. Every entry is either helping you match a requirement or diluting the ones that do.
That reframing tells you exactly what belongs there. Hard skills the role names go in. Assumed baseline skills, vague personality traits, and anything you cannot back up elsewhere on the page come out. The rest of this guide is how to make those calls.
The split
Hard skills go in the list, soft skills go in the bullets
The single most common mistake is putting soft skills in the skills section. Here is why the two kinds of skill live in completely different places.
Hard skills
Nameable and verifiable
Languages, frameworks, tools, platforms, methods, and certifications. Python, Figma, SQL, HIPAA, SEO, financial modeling. These are testable nouns, so a list is the right format and an ATS can match them cleanly.
Soft skills
Only real when demonstrated
Leadership, communication, collaboration, problem-solving. Nobody believes these because you typed them. They are only credible when you show them happening, which means they belong in your experience bullets, not a list.
The test
Could a stranger fake it?
Anyone can type "detail-oriented." Almost nobody can fake "reduced billing errors 22 percent by rebuilding the reconciliation checklist." If a skill can be claimed with zero proof, it does not belong in the list.
The rewrite
Turn the trait into a scene
Do not write "strong communicator." Write "presented the quarterly roadmap to a 40-person org and cut follow-up questions by writing a one-page brief first." The soft skill is now a fact the reader can see.
Why it matters
Recruiters discount unproven traits
Experienced recruiters mentally delete soft-skill lists because everyone claims the same five. Moving those claims into bullets is what makes them count instead of getting skimmed past.
The exception
Domain languages and tools
Some things sit in between, like a spoken language or a niche methodology. If it is nameable and a job would list it as a requirement, treat it as a hard skill and put it in the list.
The build
Build the skills section in five moves
Do these in order for each role you apply to. The section is fast to build once you stop trying to make it comprehensive.
Pull the required skills from the job post.
Read the description and list every hard skill it names, especially the ones in the requirements and responsibilities. Note the exact wording. If it says "React.js," write "React.js," not "React," because the match is on the string.
Keep only what is true.
Cross off anything you cannot honestly claim or defend in an interview. Mirroring the job description is smart. Inventing skills you do not have is how you get caught in the first technical screen. Match reality, not the wishlist.
Group what is left into a few clusters.
Sort the survivors into three or four labeled groups, such as Languages, Tools, and Methods. Grouping turns a comma soup into a scannable map and helps the reader find the one skill they came looking for.
Cut the assumed and the generic.
Remove anything a hiring manager already assumes you can do. Microsoft Word, email, and "the internet" add nothing. So do vague traits. Every line you cut makes the remaining skills easier to see.
Confirm each skill has proof elsewhere.
For every hard skill in the list, check that it also appears in an experience bullet, a project, or a certification. A skill that lives only in the list and nowhere else reads as padding. Evidence is what turns the claim into a fact.
The edit
What to keep and what to drop
Half of a good skills section is subtraction. Here is the line between what earns its place and what quietly hurts you.
| Capability | Folio | Drop it |
|---|---|---|
| Basic software everyone has | Specialized tools the role names: Salesforce, Tableau, Kubernetes | Microsoft Word, email, "the internet," Windows |
| Personality traits | Proven in a bullet: "team player" becomes "led a cross-functional team of six" | "Team player," "hard worker," "detail-oriented" in a list |
| Skill specificity | The exact term from the posting: "TypeScript," "GAAP," "paid search" | Vague umbrellas: "coding," "finance," "marketing" |
| Proficiency ratings | Let the experience and projects show the depth | Star ratings or "Python: 8 of 10" that nobody can verify |
| Length | A tight, grouped set the role actually requires | A wall of thirty words that dilutes every real match |
Rule of thumb: if a skill is assumed, unprovable, or not in the job description, it is costing you attention it does not earn.
The match
Mirror the job description without stuffing keywords
Applicant tracking systems match text. If the posting asks for "project management" and you wrote "managing projects," a strict keyword filter can miss you even though you are obviously qualified. So the move is to use the employer's own words for the skills you genuinely have. Read the description, note the exact phrasing, and let it decide the wording in your skills list. This is not gaming the system, it is speaking the language the system was told to look for.
There is a line, though, and crossing it backfires. Keyword-stuffing is when you paste the entire job description into a hidden text block, or list twenty tools you have never touched, or repeat the same phrase until the sentence stops making sense. Modern screening and, more importantly, the human who reads next, both notice. A resume that is obviously reverse-engineered from the posting reads as desperate and gets trusted less, not more.
The honest version is simple: mirror the terms for skills you actually have, drop the ones you do not, and tailor the list per application instead of shipping one generic block to every role. If checking your wording against a posting by hand feels tedious, an ATS resume checker can score the overlap and flag the exact terms you are missing, so you fix real gaps instead of guessing.
The proof
A skill is only as good as its evidence
The skills list is a set of claims. The rest of the resume is where those claims get proven or exposed. If "data analysis" is in your skills section, a recruiter's eye should land on a bullet like "built the weekly retention dashboard in SQL and Looker that the growth team runs on." If it is not there, the skill is floating, and a sharp reader treats a floating skill as an unbacked one. The strongest resumes have almost no orphan skills: every meaningful item in the list is echoed by an outcome, a project, or a certification somewhere on the page.
This is also why the skills section should be short. A list of eight targeted skills that all have evidence is far more convincing than a list of twenty-five where two-thirds are never mentioned again. Density of proof beats breadth of claims. When you cut a skill you cannot support, you are not weakening the resume, you are removing a bluff a good interviewer would have called anyway.
The clean way to keep skills and proof in sync is to generate them from one profile instead of maintaining a separate list by hand. Folio drafts your resume, cover letter, and portfolio from the same source using a leading AI model, and you review and approve every line, so a skill you claim is drawn from the same experience it appears in, and nothing drifts out of alignment. You export to clean PDF and DOCX when it is ready, and the same profile powers the version a human reads and the version the software parses.
Frequently asked questions
What skills should I put on my resume?
Put the hard skills the job description names and that you can honestly back up: tools, languages, platforms, methods, and certifications. Group them into a few labeled clusters, keep the list tight, and prove your soft skills inside your experience bullets rather than listing them.
What is the difference between hard skills and soft skills on a resume?
Hard skills are nameable and verifiable, like Python, SQL, or financial modeling, and they belong in the skills list. Soft skills are traits like leadership or communication that only become credible when demonstrated, so they belong in your experience bullets as concrete examples, not in a list.
How many skills should I list on a resume?
Enough to cover what the role requires and no more, usually somewhere around eight to twelve targeted hard skills. A short list where every skill has proof elsewhere on the page beats a long list where most items are never mentioned again.
Should I match the skills in the job description?
Yes, use the employer's exact wording for the skills you actually have, because applicant tracking systems match text and can miss close synonyms. Just do not stuff keywords or claim skills you lack, since both a modern parser and the human reader will notice.
What skills should I leave off my resume?
Drop basic software everyone is assumed to have like Microsoft Word and email, vague personality traits like "team player" or "detail-oriented," unprovable proficiency ratings, and any skill that does not appear elsewhere on the resume as evidence.