Resume Building
What Skills Should You List on a Resume?
By Pukar Khanal, Product Lead at ResumeAI
12 min readPublished
Pukar Khanal leads product at ResumeAI, working on AI resume parsing, ATS scoring, and semantic job matching. He writes about how applicant tracking systems read resumes and how job seekers get past them.
The skills to list on a resume are the ones the posting names that you can defend, and the ones that carry weight are evidenced inside your accomplishment bullets. Your skills section is a lookup aid for a human skimming and a surface a keyword search can hit. It is not evidence.
ResumeAI, the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market, reviewed this question on 22 July 2026.
Key takeaways
- A list is an assertion. A list says you have a skill. A bullet shows the skill doing something.
- Hard skills belong in the list. They are checkable, so a reader can ask you about them.
- Soft skills belong in bullets. Team player and strong communicator are unverifiable in a list. Show the quality in an accomplishment instead.
- Derive the list from the posting. Keep only what you could discuss for five minutes under questioning, in the employer's vocabulary.
- Drop rating bars. Plain grouped text extracts reliably and reads quickly.
What you will not find below
There is no list of the skills employers want this year on this page. Almost every competing page for this question hands you one, and almost none says where it came from. We could not verify any such ranking from a source willing to show its working, so we have not published one. You get a way to decide which skills belong on your document instead, and a method for deriving them from the posting in front of you.
Does the skills section actually matter?
Less than the advice around it implies. A skills section does two narrow jobs. It is a lookup aid, so a reader who wants to know whether you have used a tool can find out in a second instead of reading three roles. And it is a surface a search can hit, so its terms are findable by whatever reads your document, human or otherwise.
It is not evidence. A list is an assertion, and an assertion costs nothing to make. Anybody can type any word into a skills section, and readers discount the list for it. Not consciously, and not to zero, but the discount is large. In a list, a language you shipped production systems in takes the same space as one you followed a Sunday tutorial in.
The distinction the rest of this page runs on
A list says you have a skill. A bullet shows the skill doing something. Only the bullet survives a reader deciding between you and somebody else, because only the bullet carries a scope, a context and an outcome they can ask about. Treat the section as an index into your experience, and most questions about what to put in it answer themselves.
This is why the giant skill lists in this search result are so unsatisfying. They answer a question about inventory when the reader has a question about selection. Nobody needed to learn that project management exists as a skill. The question is whether your project management belongs on this document, in the list or in a bullet, and no generic inventory can answer that.
What is the difference between hard skills and soft skills on a resume?
Hard skills are checkable. Soft skills asserted in a list are not, and that asymmetry should decide how you handle each. A hard skill names something specific enough to examine: a language, a tool, a platform, a methodology, a credential, a body of domain knowledge. Put one in a list and a reader can ask you about it, so the entry works as an invitation.
A soft skill describes how you work with people and how you think. In a list it is a word nobody can check, sitting next to the same word on every other document that week.
Team player, detail-oriented and strong communicator are near-worthless in a skills section. The qualities matter enormously, and the hiring decision often turns on them. But in that position they are unverifiable, and a reader who cannot check a claim has to ignore it.
The same qualities are powerful one section down. Picture a bullet about taking an ambiguous request, working out what was needed and getting three teams to agree on it. That shows collaboration and communication in a form somebody can weigh, disagree with or ask about. The quality should be the reader's inference, not your assertion.
What a public taxonomy calls these things
One external source loaded in full when we went looking. O*NET OnLine, the public occupational taxonomy published by the United States Department of Labor, describes soft skills (read on 22 July 2026) as "interpersonal and thinking skills needed to interact successfully with people and to perform efficiently and effectively in the workplace". It groups them into social skills and thinking skills.
Its browse pages define transferable skills as "skills you can use across different jobs, such as communication, problem solving, and team work", and essential skills as "skills you need for most jobs, such as reading, writing, math, and learning".
The structure is more useful than the definitions. On an O*NET occupation profile, named software sits in its own section, separate from the essential and transferable skill categories. A government taxonomy with no interest in resumes still keeps named tools apart from general capabilities. That suggests the hard-and-soft split on resumes tracks a real difference in kind.
The taxonomy does not tell you which skills are in demand, or what belongs on your document, and neither does this page. Those are resume-construction judgements, and the next section covers them.
Which skills belong in the skills section, and which belong somewhere else?
Find the kind of skill you are holding and read across: whether it belongs in the section, where it earns its keep, and how to evidence it. Every cell is a judgement about resume construction, not a claim about anybody's hiring behaviour. No row depends on a statistic or a source.
| Type of skill | Does it belong in the skills section? | Where it earns its keep | How to evidence it |
|---|---|---|---|
| Named tools, languages and platforms | Yes. This is what the section is for. | In the list, where a skimming reader and a keyword search can both find it quickly, and again inside the bullets where you used it. The list answers do they have it. The bullet answers what did they do with it. | Name the tool inside an accomplishment bullet with the scope and the outcome attached, so the reader sees it doing work. One good bullet is worth more than five list entries. |
| Certifications and licences | Only as a pointer. They belong in their own labelled section. | In a dedicated certifications or licences block where the issuing body and the date are visible. A credential is a claim somebody else made about you, which makes it worth more than a self-assertion. | Give the full name of the credential and who issued it. If it is a hard requirement in the posting, put it somewhere a skim will hit, not only at the bottom of the last page. |
| Methodologies and frameworks | Yes, when the posting names them. Otherwise they are usually better shown than listed. | Inside the experience, where the reader can see how you worked. A methodology in a list says you have heard of it. A methodology in a bullet says you have run under it. | Describe a thing you did within that way of working, not the fact that the team used it. Interviewers probe for the difference between being present for a practice and driving it. |
| Domain knowledge | Sometimes, and it is often better placed in a summary line or a section heading. | Wherever it explains why your experience transfers to this employer. Domain knowledge makes an ordinary background the obvious fit, and a one-word list entry wastes it. | Show it through the problems you solved and the vocabulary you use to describe them. A reader in that domain spots somebody who has worked in it within a sentence or two. |
| Soft and interpersonal skills | Generally no. Asserting them in a list is unverifiable and buys almost nothing. | Inside accomplishment bullets, where the behaviour is visible and the reader can weigh it. The exception is a posting that explicitly names an interpersonal capability as a requirement. Mirror that somewhere defensible. | Write the bullet so the quality is the obvious inference. Getting three teams to agree on a scope is collaboration. The word collaboration is not. |
| Spoken languages | Yes, and a separate languages line is usually cleaner if there are several. | Wherever it is relevant to the role, the team or the market. A plain list handles this well, because it is checkable and the reader knows what the categories mean. | State a level using a term with a shared meaning, not a personal scale. If you claim working fluency, expect the interview to be held in that language. |
| Skills shown with rating bars or stars | No, in this form. Convert them to plain text. | Nowhere as a graphic. The rating lives in a shape, not in text, so extraction has nothing to extract. The reader may receive a bare skill name with the meaning stripped off. | Replace the scale with grouping and with bullets. If the gap between your strongest and weakest tools matters, show it by which ones appear in your accomplishments. |
Read the third column downwards. Almost everything earns its keep somewhere other than the list. The section is worth having and worth keeping tidy, but it is a way into your experience, not a replacement for it.
How do I choose which skills to list?
Derive them from the posting in front of you, not from anybody's list, including ours. The posting is the only document that knows what this employer wants, and it is written in their vocabulary. This method takes about as long as reading this page, and you can repeat it for every application.
- 1
Paste the posting into a plain text editor
Use a plain text buffer, not a document or a formatted note. A posting's formatting makes it feel coherent, and you are about to take it apart. Include the whole thing: responsibilities, requirements and the paragraph about the team, because the specifics are scattered.
- 2
Mark every noun-phrase that names something concrete
Mark each phrase naming a tool, a language, a platform, a methodology, a domain, a credential or a named process. Ignore adjectives and anything describing a personal quality. What's left is the employer's own vocabulary for what this job is made of.
- 3
Split the marked list into three piles
Pile one: things you have and could discuss for five minutes under questioning. Pile two: things you have touched but could not defend. Pile three: things you do not have. Be strict. Nobody sees this but you, and the step only works if the sorting is honest.
- 4
Discard pile three entirely
It goes nowhere on the document. A skill you do not have is a claim that fails at the first specific question, and that failure recolours everything else on the page. A missing skill is a gap. A skill you cannot discuss is a credibility problem.
- 5
Put pile two nowhere either, for now
People get this pile wrong. Something you touched once feels like a fair entry, but in an interview it is a trapdoor. The question after a listed skill is what you did with it. If pile two matters to you, move an item into pile one by using it, not by promoting it on paper.
- 6
Write pile one using the employer's vocabulary
Where the posting's word and your word describe the same thing, use theirs. Keyword stuffing pads a document with terms to game a filter. This is picking, from two accurate labels for something you did, the one your reader already uses. Only do it for skills that are yours.
- 7
Check that the important ones appear in a bullet too
Take the few items from pile one that the posting leans on hardest. Confirm each one also appears inside an accomplishment bullet with a scope and an outcome. A critical skill that exists only in your list is asserted, not evidenced, and this pass is where you fix it.
Using their vocabulary is not keyword stuffing
People raise this objection at the sixth step. Keyword stuffing pads a document with terms to game a filter, and it fails twice. It reads badly to the person who opens the file, and it leaves you defending words you chose for a machine. Picking the employer's label for something you did, from two accurate labels, removes a translation step. Somebody or something on the other end would otherwise have to make it, and might not.
The boundary is honesty. Only mirror wording for skills that are yours. The broader tactics for getting through automated screening are in how to get past an ATS, so we won't restate them here.
Will a screener recognise my skill if I word it differently?
It depends on what class of system is reading you, and you usually cannot tell from the outside. An exact-string matcher looks for the characters it was given. A term written one way can be absent as far as it is concerned when the posting writes it another way. A matcher built on meaning can connect terms that describe the same thing, because it compares what the words are about.
The equivalences worth thinking about are ordinary ones. Your resume says internal services where the posting names a cloud provider. It names a company's own orchestration system where the posting names the open-source project it inspired. It says a managed cluster service where the posting names the underlying platform. Or one query language where the posting names another, or data pipelines where the posting uses the three-letter term.
To a person these pairs are obviously related. To an exact-string matcher they are unrelated tokens. The fix costs nothing: where you have done the thing, use the label the posting uses.
How meaning-based screening reads a resume, and what that changes about your writing, is covered in how LLM resume screening differs from keyword ATS.
To see the mechanism, our ATS embedding visualizer runs it on your own text. Paste a resume and a job description as plain text. It turns both into semantic embeddings, projects them into one shared two-dimensional space, and draws a line from each job-description requirement to the closest resume chunk. It is free, there is no signup, and it takes a paste, not a file.
What should you not put in a skills section?
Three things, and each fails for a different reason.
Rating bars, star ratings and percentage dials
These fail twice. The rating lives in a graphic, so a system extracting the words from your file has nothing to extract. Depending on how the document was built, the reader can receive a bare skill name with the meaning stripped off.
Even when they survive, they are unfalsifiable. Nobody can tell you what four filled circles beside a programming language means, and you cannot tell them. The next candidate using the same scale is not describing the same thing. You have spent the most prominent space in the section on a claim with no information in it.
Padding with skills you cannot discuss
Use the test from the method: could you talk about this for five minutes with somebody who does it for a living? If not, leave it off. A listed skill is an invitation, and the follow-up question is what you did with it. A confident answer is the best moment in an interview.
A vague answer is the worst. It costs you that item, and it makes the reader re-examine everything else in the list. Once the benefit of the doubt is gone, you don't get it back.
Tools you touched once, and words that sound impressive
A tool you opened for an afternoon on somebody else's project is pile two, and pile two goes nowhere. The related failure is inflated vocabulary to make an ordinary list sound senior. It makes a document read as generated. The specific words that trigger it are in the words that make your resume sound AI-written. In a skills section, name the thing what the people who use it call it.
Where does the skills section go, and how long should it be?
Near the top when the hard skills are the qualification, and lower when the experience is. That is a judgement about your document, not a convention with a correct answer. If the posting is mostly an inventory of tools and your case rests on having them, don't make a skimming reader hunt. If the posting is buying judgement and assumes the tools, lead with experience.
Length is a range, not a count. Long enough to cover what the posting names and what you can defend, short enough that a skimmer can read it. Anyone who gives a precise number is inventing it. Too short and a tool the posting asked for is missing, so a reader works harder and a search fails. Too long and the important items get harder to spot.
Two neighbouring decisions matter more, and both have their own pages. Whether your layout survives software at all is covered in the ATS-friendly resume format. Which overall structure to use is covered in the best resume format. A perfectly placed skills section in a document that doesn't extract cleanly gains you nothing.
If you are early in your career and pile one is very short, don't inflate it. Build the document around coursework, projects and the work you have done. That is what what to put on a resume with no experience covers. A short defensible list reads far better than a long one that collapses at the first specific question.
Where does ResumeAI fit into this?
Disclosure
We make resume software, so treat this section as a pitch. Nothing above depends on our product. The method works with a plain text editor and the posting you are applying to.
ResumeAI is the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market. The relevant part here is the ATS resume checker. It reads your document the way automated screening does and compares it against a job description, so you can see which of the posting's terms your file carries. It checks the output of the method. Only you can sort the piles, because only you know what you could defend.
If the document itself is the problem, our free resume templates are single-column editable starters you can download and fill in without an account. They won't decide what goes in your skills section. They will stop the layout from hiding it.
How we know this, and what we did not verify
This article was written by Pukar Khanal, Product Lead at ResumeAI, and last reviewed on . ResumeAI is the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market.
We speak first-hand about the machine-reading end. We build an ATS resume checker that parses documents and compares them against job descriptions, and an embedding visualizer that shows which requirement reaches which phrase. Everything here about how software reads a skills list comes from that work.
This page publishes no ranking of in-demand skills, because no such ranking could be verified. It is the most common thing on competing pages and the thing we could least support. We don't say what employers want this year, or that any skill is rising or falling. If a page does, ask where the ordering came from.
One external source loaded in full and it is the only one cited. O*NET OnLine returned readable pages across every path we tried on the review date. We quote only what it says, linked where used.
Several other attempts produced nothing usable. Two paths into the federal career exploration site returned a forbidden response. One Ivy League career page returned a content-delivery block behind a success status, and another university refused the connection. A federal statistics article was forbidden, and two government resume paths returned not-found. Two university career pages loaded but had no guidance on the skills section, so they are not cited.
Parser behaviour is described in principle, not per vendor. The contrast between exact-string matching and matching on meaning describes how two classes of system differ by design. It says nothing about any named product, because configurations vary and we have not tested them. There are no statistics on this page. The only digits are dates and the reading time.
We cannot tell you which skills belong on your resume, because that depends on a posting we haven't read. We can tell you that a list is an assertion and a bullet is a demonstration. The method above beats any generic inventory, and the sorting in step three does the work.
Frequently asked questions
What skills should I put on my resume?
The ones the posting names that you genuinely have, written in the posting's own vocabulary, plus the tools and credentials a reader would need to see before taking your experience seriously. That is a shorter and more specific answer than the long generic lists this question usually attracts, and it is more useful, because the right list is different for every application. The more important point is where those skills live. A skills section is a lookup aid for a person skimming and a surface a keyword search can hit, but it is not evidence, because anybody can type anything into a list. A skill only becomes evidence when a bullet in your experience shows it doing something with a scope and an outcome attached. So the practical sequence is to derive the list from the posting, keep it to things you could discuss for five minutes under questioning, and make sure the ones that matter most also appear inside your accomplishment bullets rather than only in the list.
What is the difference between hard skills and soft skills on a resume?
Hard skills are checkable and soft skills asserted in a list are not, and that asymmetry decides how each should be handled. A hard skill names something specific: a language, a tool, a platform, a methodology, a credential, a body of domain knowledge. A reader can ask you about it, and an interview will establish quickly whether you have it. That is exactly why hard skills work in a list, and why a list of them is a reasonable lookup aid. Soft skills describe how you work with people and how you think. They are genuinely important, and they are also the part of a resume where a list does the least work, because a reader has no way to check the claim and has seen the same words on every other document that week. The distinction is not about which matters more in the job. It is about which can survive being asserted rather than shown.
Should I list soft skills on a resume?
Mostly not as a list, and this is one of the few places where common advice and honest advice come apart. Writing team player, detail-oriented or strong communicator into a skills section costs you space and buys you almost nothing, because the words are unverifiable where they sit and every competing document contains them. Nobody has ever been advanced for typing them. What does work is demonstrating the same qualities inside an accomplishment bullet: a bullet describing how you took an ambiguous request, worked out what was actually needed and got three teams to agree on it shows collaboration and communication in a form a reader can weigh. There are exceptions worth knowing. If a posting explicitly names an interpersonal capability as a requirement, mirroring that phrase somewhere on the document is reasonable, because a search for it may well be run. Put it where it is defensible rather than where it is decorative.
How many skills should I list on a resume?
Enough to cover what the posting names and what you can defend, and few enough that somebody skimming can actually read the list. That is a judgement rather than a rule, and any page that gives you a precise count is inventing it, because the right length depends on your field, your seniority and the specific posting. Two failure modes bracket the sensible range. A list so short that it omits tools the posting explicitly asked for makes a reader work to find out whether you have them, and a keyword search will simply not find them. A list so long that it includes everything you have ever opened dilutes the signal, makes the important items harder to spot and creates interview exposure on things you cannot discuss. The test that replaces the count is this: could you talk about every single item for five minutes under questioning? If not, the list is too long regardless of its size.
Where does the skills section go on a resume?
Near the top when the hard skills are the qualification, and lower when the experience is. For a technical role where the posting is largely a list of tools and platforms, putting them where a skimmer sees them first is sensible, because that is what the reader is scanning for and there is no reason to make them hunt. For a role where the judgement is what is being bought and the tools are assumed, the experience should lead and the skills section can sit underneath as a reference block. This is a judgement about your document and the specific posting rather than a rule with a right answer, and reasonable people order it differently. Two things matter more than placement. The heading should be a plain one that a reader and a parser both recognise, and the skills that carry the most weight should also appear inside your accomplishment bullets rather than living only in the list.
Should I use skill rating bars or star ratings?
No, and the reason is worth understanding because it applies to a whole family of design choices. A rating bar is a graphic, so whatever meaning you intended lives in the shape rather than in the text, and text extraction has nothing to extract. Depending on how the file was built, a reader on the other end can end up with a bare skill name and no rating at all, which is at best neutral and at worst confusing. The deeper problem is that the ratings are unfalsifiable even when they survive. Nobody can tell you what four filled circles next to a language means, you cannot tell them, and two candidates using the same scale are not describing the same thing. You have spent visual space on a claim that carries no information. Plain grouped text is better on every axis: it extracts reliably, it reads quickly, and it does not invite a question you cannot answer.
Do I need to match the exact wording of the job description?
Matching the employer's vocabulary for skills you genuinely have is sensible, and it is not the same thing as keyword stuffing. If the posting says one term and your resume says a different term for the identical thing, you are relying on whatever is reading your document to know that the two are equivalent. Some systems do: matching that works on meaning rather than on characters can connect terms that mean the same thing. Others do not, because an exact-string matcher can only find the characters it was given. Since you rarely know which class of system is reading you, using the employer's word for something you have actually done is a free reduction in risk. Two boundaries make this honest rather than manipulative. Only mirror wording for skills you truly have, and only where it reads naturally to a person, because a human is going to read the same document and a block of pasted terminology reads exactly like what it is.
What to ask next
Each of these links to the page that answers it.
See which of a posting's terms your resume carries
Run the method above first, then check the result. Our ATS checker reads your document the way screening software does and compares it against a job description. The embedding visualizer shows which requirement reaches which phrase.
Related guides