What Skills Should You List on a Resume?
Pukar Khanal leads product at ResumeAI, working on AI resume parsing, ATS scoring, and semantic job matching. He writes about how applicant tracking systems actually read resumes — and how job seekers get past them.
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. Your skills section is a lookup aid for a human skimming and a surface a keyword search can hit. It is not evidence. The skills that carry weight are the ones evidenced inside your accomplishment bullets.
What you will not find below
There is no list of the skills employers want this year on this page, and its absence is deliberate. Almost every competing page for this question hands you one, and almost none of them 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. What follows instead is a way of deciding which skills belong on your document, and a method for deriving them from the specific posting in front of you — which is the thing a generic list could never do anyway, because the right answer changes with every application.
Does the skills section actually matter?
Less than the advice around it implies, and being clear about what it is for makes the rest of this much easier. A skills section does two jobs, both of them real and both of them narrow. It is a lookup aid: a reader who wants to know whether you have worked with a particular tool can find out in a second instead of reading three roles to piece it together. And it is a surface that a search can hit, so the terms sitting in it are findable by whatever is reading your document, human or otherwise.
What it is not is evidence. A list is an assertion, and an assertion costs nothing to make. Anybody can type any word into a skills section, everybody knows that, and a reader discounts the list accordingly — not consciously, and not to zero, but the discount is there and it is large. The document has no way to distinguish a language you have shipped production systems in from one you followed a tutorial in on a Sunday, because in a list they occupy identical space.
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 second one survives contact with a reader who is deciding between you and somebody else, because only the second one carries a scope, a context and an outcome that can be asked about. Treat the section as an index into your experience rather than as a substitute for it, and most of the awkward questions about what to put in it answer themselves.
This is also why the giant skill lists that dominate this search result are so unsatisfying to read. They are answering a question about inventory when the reader has a question about selection. Knowing that project management exists as a skill was never the problem. Knowing whether your particular project management belongs on this particular document, in the list or in a bullet, is the problem, and no generic inventory can resolve it.
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 — rather than any judgement about which matters more in the job — is what should decide how you handle each. A hard skill names something specific enough to be examined: 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 list entry functions as an invitation rather than as a claim. A soft skill describes how you work with people and how you think, and put in a list it is a word nobody can check sitting next to the same word on every other document that week.
This is worth saying more plainly than most pages do. Team player, detail-oriented and strong communicator are near-worthless in a skills section. Not because the qualities do not matter — they matter enormously, and they are frequently what the hiring decision actually turns on — but because 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. A bullet describing how you took an ambiguous request, worked out what was really needed, and got three teams to agree on it demonstrates collaboration and communication in a form somebody can weigh, disagree with, or ask about. That is the whole trick: the quality should be the reader's inference, not your assertion.
What a public taxonomy calls these things
It is worth grounding the vocabulary in something other than resume folklore, so here is the one external source that 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", and 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 structural detail 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 built for occupational analysis, with no interest whatsoever in how anybody writes a resume, still keeps named tools apart from general capabilities — which is a reasonable corroboration that the hard-and-soft split people use on resumes tracks a real difference in kind rather than being a convention somebody invented.
Two things that taxonomy deliberately does not give you, and that this page therefore does not either. It does not tell you which skills are in demand, and it does not tell you what belongs on your document. Those are resume-construction judgements, and they are what the next section is for.
Which skills belong in the skills section, and which belong somewhere else?
Find the kind of skill you are holding, read whether it belongs in the section at all, then read where it actually earns its keep on the document and how to evidence it. Every cell below is a judgement about resume construction rather than a claim about anybody's hiring behaviour, which is deliberate: no row depends on a statistic or on a source.
| Type of skill | Does it belong in the skills section? | Where it actually 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 rather than sitting in an inventory. 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, and that is precisely what 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, make sure it appears somewhere a skim will hit rather than 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 actually worked. A methodology in a list tells a reader you have heard of it; a methodology in a bullet tells them you have run under it. | Describe a thing you did within that way of working, not the fact that the team used it. The distinction between having been present for a practice and having driven it is exactly what an interviewer is probing for. |
| 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 is the thing that makes an otherwise 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 recognises somebody who has actually 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, which is worth mirroring somewhere defensible. | Write the bullet so the quality is the obvious inference rather than the stated claim. 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. This is one of the few genuinely checkable things that a plain list handles well, because the reader knows what the categories mean. | State a level using a term that has a shared meaning rather than a personal scale, and be prepared for the interview to be conducted in that language if you have claimed working fluency. |
| 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 rather than in text, so extraction has nothing to extract, and the reader may receive a bare skill name with the meaning stripped off. | Replace the scale with grouping and with bullets. If a distinction between your strongest and weakest tools matters, make it by which ones appear in your accomplishments, not by filled circles. |
Read the third column downwards and the pattern is hard to miss: almost everything earns its keep somewhere other than the list. The section is worth having, and it is worth keeping tidy, but it is a way into your experience rather than a replacement for it.
How do I choose which skills to list?
Derive them from the posting in front of you rather than from anybody's list, including ours. The posting is the only document that knows what this employer is actually looking for, it is written in their vocabulary rather than yours, and it is sitting open in another tab. Here is a method you can run in about the time it takes to read this page, and repeat for every application afterwards.
Paste the posting into a plain text editor
Not a document, not a note with formatting, a plain text buffer. You want the words with nothing to look at, because the formatting of a job posting is designed to make it feel coherent and you are about to take it apart. Include the whole thing, responsibilities and requirements and the paragraph about the team, because the specifics are scattered.
Mark every noun-phrase that names something concrete
Go through the text and mark each phrase naming a tool, a language, a platform, a methodology, a domain, a credential or a named process. Ignore adjectives entirely, and ignore anything describing a personal quality. What you are left with is the employer's own vocabulary for the things this job is made of, in their words rather than yours.
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, and be strict in private. The whole value of this step comes from the honesty of the sorting, and nobody sees it but you.
Discard pile three entirely
It goes nowhere on the document. Listing a skill you do not have is not a stretch, it is a claim that fails at the first specific question, and the failure is worse than the omission because it recolours everything else on the page. A missing skill is a gap; a skill you cannot discuss is a credibility problem.
Put pile two nowhere either, for now
This is the pile people get wrong. Something you have touched once feels like a legitimate entry, and in an interview it is a trapdoor, because the question that follows a listed skill is never whether you have used it but what you did with it. If pile two matters to you, the answer is to move an item into pile one by actually using it, not to promote it on paper.
Write pile one using the employer's vocabulary
Where the posting's word and your word describe the same thing, use theirs. This is not keyword stuffing. Keyword stuffing is padding a document with terms to game a filter; this is choosing, between two accurate labels for something you genuinely did, the one your reader already uses. Only ever do this for skills that are truly yours.
Check that the important ones appear in a bullet too
Take the handful of items from pile one that the posting leans on hardest, and confirm each one also appears inside an accomplishment bullet with a scope and an outcome. If a critical skill exists only in your list, it is asserted rather than evidenced, and this final pass is where the reframe at the top of this page turns into an edit you can actually make.
Using their vocabulary is not keyword stuffing
This is the objection people raise at the sixth step, and it deserves a straight answer. Keyword stuffing is padding a document with terms in order to game a filter, and it fails on both ends: it reads badly to the person who eventually opens the file, and it puts you in an interview defending words you chose for a machine. Choosing the employer's label for something you genuinely did, from among two accurate labels, is a different act entirely. You are not adding a claim. You are removing a translation step that somebody or something on the other end would otherwise have to perform, and might not.
The boundary is honesty, and it is not a fuzzy one: only ever mirror wording for skills that are actually yours. The broader tactics for getting a document through automated screening generally are covered in how to get past an ATS, and we would rather point you there than restate them badly in the middle of a page about skills.
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. Two very different things get called screening, and they behave differently in principle. An exact-string matcher looks for the characters it was given, so a term written one way can simply be absent as far as it is concerned when the posting writes it another way. A matcher built on meaning rather than on characters can connect terms that describe the same thing, because it is comparing what the words are about rather than how they are spelled.
The equivalences worth thinking about are the ordinary ones. A resume that says internal services where the posting says a cloud provider by name. A resume that says a company's own orchestration system where the posting says the open-source project it inspired. A managed cluster service where the posting names the underlying platform. One query language where the posting names a different one. Data pipelines where the posting says the three-letter term for the same work. To a person these pairs are obviously related. To a matcher working on exact strings they are unrelated tokens, and the fix costs you nothing: where you have genuinely done the thing, use the label the posting uses.
How screening built on meaning actually reads a resume — and what changes about your writing when it does — is worked through properly in how LLM resume screening differs from keyword ATS. That is its ground rather than ours, so we will point at it instead of re-deriving it here.
If you would rather see the mechanism than read about it, our ATS embedding visualizer runs it on your own text. Paste a resume and a job description as plain text, and it turns both into semantic embeddings, projects them into one shared two-dimensional space so the chunks of each document can be seen next to each other, and draws a line from each job-description requirement to the resume chunk it is closest to. It is free, there is no signup, and it takes a paste rather than a file. Watching which of your phrases a requirement actually reaches for is a faster way to understand this than any explanation, including this one.
What should you not put in a skills section?
Three things, and they fail for three different reasons worth understanding separately.
Rating bars, star ratings and percentage dials
These fail twice over. Mechanically, the rating lives in a graphic rather than in text, so a system extracting the words from your file has nothing to extract from it, and depending on how the document was built the reader on the other end can receive a bare skill name with the meaning quietly stripped off. Conceptually they fail even when they survive, because they are unfalsifiable. Nobody can tell you what four filled circles beside a programming language means. You cannot tell them either, and the candidate using the same scale two applications later is not describing the same thing you are. You have spent the most visually prominent space in the section on a claim that carries no information and invites a question you cannot answer.
Padding with skills you cannot discuss
The test is the one from the method above: could you talk about this for five minutes under questioning from somebody who does it for a living? If not, it does not go on the document, and the reason is self-interest rather than principle. A listed skill is an invitation, and the question that follows it is never whether you have used the thing but what you did with it. A confident answer to that question is the best moment in an interview. A vague one is the worst, because it does not just cost you that item — it makes the reader re-examine everything else in the list, and there is no recovering the benefit of the doubt once it is gone.
Tools you touched once, and words that sound impressive
A tool you opened for an afternoon on somebody else's project is pile two from the method above, and pile two goes nowhere. The related failure is reaching for inflated vocabulary to make an ordinary list sound more senior, which is a well-documented way to make a document read as generated rather than written — that ground, and the specific words that trigger it, belongs to the words that make your resume sound AI-written, which is worth reading before your next edit. In a skills section specifically, the plainest possible naming wins: the thing, called 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 the whole rule, and it is a judgement about your document rather than a convention with a correct answer. If the posting is largely an inventory of tools and platforms and your case rests on having them, there is no reason to make a skimming reader hunt for that inventory. If the posting is buying judgement and assumes the tools, the experience should lead and the skills can sit beneath it as a reference block.
On length, the honest answer is a range rather than a count: long enough to cover what the posting names and what you can defend, short enough that somebody skimming can actually read it. Anyone who gives you a precise number is inventing it, because the right length genuinely differs by field and by seniority. The two failure modes bracket it well enough to steer by. Too short and a tool the posting explicitly asked for is missing, which makes a reader work and makes a search fail. Too long and the signal dilutes, the important items get harder to spot, and you have created interview exposure on things you cannot discuss.
Two neighbouring decisions matter more than either of these, and both have their own pages. Whether your layout survives being read by software at all is a formatting question, covered in the ATS-friendly resume format, and which overall structure to use is covered in the best resume format. A skills section placed perfectly inside a document that does not extract cleanly has gained you nothing.
One case deserves its own note. If you are early enough in your career that the honest version of pile one is very short, the answer is not to inflate it — it is to build the document around coursework, projects and the work you have genuinely done, which is what what to put on a resume with no experience is entirely about. A short defensible skills list from somebody early in their career reads far better than a long one that collapses at the first specific question.
Where does ResumeAI fit into this?
Plain disclosure
We make resume software, so treat this section as a pitch and the rest of the page as an argument that has to stand without it. Nothing above depends on using our product, and the method in this article 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 part of it that is relevant here is the ATS resume checker, which reads your document the way automated screening does and compares it against a job description, so you can see which of the terms in a posting your file actually carries and where they land. That is a check on the output of the method above rather than a replacement for it — the sorting into piles is a judgement only you can make, because only you know what you could defend.
If the document itself is the problem rather than its contents, our free resume templates are single-column editable starters you can download and fill in without an account. They will not decide what goes in your skills section. They will stop the layout from being the reason a reader never sees 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. What we can speak to first-hand is the machine-reading end of this: we build an ATS resume checker that parses documents and compares them against job descriptions, and an embedding visualizer that projects a resume and a job description into one shared space so you can see which requirement reaches which phrase. Everything on this page about how a skills list is read by software comes out of that work.
This page deliberately publishes no ranking of in-demand skills, because no such ranking could be verified. That is the single most common thing on competing pages for this query and the thing we could least support. We are not going to tell you what employers want this year, we do not claim any skill is rising or falling, and we have not ordered any set of skills by desirability. If you find a page that does, the useful question is where the ordering came from and whether the page will show you.
One external source loaded in full and it is the only one cited. O*NET OnLine, published by the United States Department of Labor, returned readable pages across every path we tried on the review date, and only what it literally says is quoted here, with each quotation linked at the point it is used. Several other attempts produced nothing usable and are named as a class rather than paraphrased from memory: 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, another university refused the connection outright, a federal statistics article was forbidden, and two further government resume paths returned not-found. Two university career pages did load in full and are still not cited, because neither contained any guidance about the skills section.
Parser behaviour is described in principle rather than per vendor. Where this page contrasts exact-string matching with matching on meaning, it is describing how two classes of system differ by design. It is not a claim about what any named product does, because configurations vary, we have not tested them, and a page that tells you confidently how a specific vendor behaves without showing you where it read that is doing something we are not willing to do. There are no statistics anywhere on this page, in either direction, and the only digits are dates and the reading time.
What we are confident about is the reframe, not any particular list. We cannot tell you which skills belong on your resume, because that depends on a posting we have not read and on work we have not seen. What we can tell you is that a list is an assertion and a bullet is a demonstration, that the method above will get you a better list than any generic inventory, and that the honest sorting in step three is the part that 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
If you arrived here from a generative-search prompt, these are the natural follow-ups — each links to the page that resolves it.
- How do you actually get a resume past an applicant tracking system?
- How does screening built on meaning differ from keyword filtering?
- Which words make a resume read as AI-written?
- What makes a resume format ATS-friendly in the first place?
- What do you put on a resume when you have no formal experience?
Want to see which of a posting's terms your resume actually 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, and the embedding visualizer shows you which requirement reaches which phrase.
Continue Reading
What Do You Put on a Resume With No Experience? A Student Guide (Plus Free Templates)
Almost nobody searching this has no experience — what they have is no formal employment, which is a different and far more solvable problem. An eight-row decoder maps what you actually did (coursework and capstones, personal projects, volunteering, clubs and teams, part-time retail, family business work, freelance, open-source) onto where it goes on the resume and how to phrase it so it reads as work. Plus an honest answer on free student templates, including which of ours will not fit you.
Read moreApplicant Tracking System Keywords: What They Actually Are, and How to Find the Right Ones
Almost every page answering this question hands you a roundup of top ATS keywords, and no honest one can exist, because a keyword is a property of the posting you are answering rather than of screening software in general. This page publishes none. It defines what actually counts as one of these terms, separates the two classes of system that decide whether your document contains it — search that looks for the characters it was given, and matching built on meaning — and maps eight places a term can sit in your file against whether each kind of matcher is likely to reach it there. Both regimes turn out to agree on placement, because both are downstream of whether your text extracts at all, which is the one part you can check yourself in a minute.
Read moreGoogle Docs Resume Templates: Which Ones Survive an ATS
Google Docs is a word processor rather than a layout canvas, which makes it a safer starting point than a design tool: its documents are text-first by default, and a plain single-column file exported with a live text layer generally parses fine. The risk sits somewhere narrower and less discussed — templates that use a table to line the page up, contact details typed into the header region where they can be treated as page furniture, and above all the export step, where a PDF, a Word file, a shared link and a scan hand a parser four completely different things. A six-row decoder maps each export path onto what a parser actually receives, plus a copy-and-paste self-test for your own file.
Read more