Put in the skills you could be questioned on for twenty minutes, grouped so a recruiter can scan them in a few seconds, and ordered so the ones the job description asks for come first. Cut everything else: the soft skills, the tools everyone uses, the language you touched once in second year.
That's most of it. The rest of this post is about the judgement calls.
Who reads the skills section
Two readers, mainly.
The first is the screening step, which might be software or might be a recruiter with the job description open in another tab. Either way, it's matching words. If the posting says Kubernetes and your resume says "container orchestration", a human may make the connection and a keyword filter won't. Use the names the industry uses.
The second is the interviewer, who reads it looking for questions. Every item in your skills section is an invitation. "I see you've listed Kafka. Tell me how you'd handle a consumer falling behind." If the honest answer is that you followed a tutorial once, that's a bad ten minutes, and it colours how the interviewer reads everything else you've claimed.
So the section has to do two jobs: match the posting, and hold up under questioning. Those two pull against each other, and the second wins.
How to structure it
Group by category, one line each. For a software engineer, something like:
Languages: Java, Python, SQL
Frameworks: Spring Boot, Django
Data and infrastructure: PostgreSQL, Redis, Kafka, Docker, AWS (EC2, S3, Lambda)
Tools: Git, Jenkins, Grafana
For a product manager:
Product: roadmapping, PRDs, A/B test design, user interviews
Analytics: SQL, Mixpanel, Amplitude, Excel
Tools: Jira, Figma (reviewing and commenting), Notion
For a designer:
Design: interaction design, design systems, prototyping, usability testing
Tools: Figma, Framer, Maze
Plain text, commas, one line per group. No proficiency bars, no star ratings, no percentages. "Python: 4/5" means nothing to the reader, and the parser in an application system will turn your nice graphic into garbage or skip it entirely. Keep the whole section to four or five lines; it supports the experience section and shouldn't compete with it.
What to put first
Order within each line matters a little and costs you nothing. If the posting leads with Go and Postgres, and you have both, put them first in their lines.
This is a legitimate kind of tailoring: you're reordering things that are true, and adding nothing that isn't. If you're applying to backend roles at product companies and full-stack roles at startups, it's reasonable to keep two versions of the line. Our guide on tailoring your resume for each job goes through where that kind of editing stops being honest.
Prove it in the bullets
A skills section on its own is a list of claims. The bullets in your experience section are where you back them up.
If Kafka is in your skills, somewhere in your experience there should be a line showing you used it, ideally with what it was for:
Moved order events from synchronous REST calls to Kafka topics, so a slow inventory service no longer held up checkout.
When a reviewer sees the skill listed and then sees it used in context, it counts for a lot more than either one alone. When a skill appears only in the skills list and nowhere in your work, a careful reviewer will notice. See writing bullet points that get read for more on making those lines specific.
What to cut
Here's what I'd delete from most resumes:
- Soft skills. "Communication", "teamwork", "leadership", "problem-solving". Everybody lists them, nobody believes them from a list, and they take up the space a real skill could use. Show leadership in a bullet about leading something.
- Universal tools. MS Office, Windows, Google Docs, "Internet". If the role is a software engineer, Word is assumed. The exception is advanced Excel for analyst or PM roles, where it's a real differentiator; say what you do with it.
- Things you can't defend. The language from one college assignment, the framework from a weekend tutorial, the cloud certification topic you've never deployed on. Remove them, or move them to a line clearly marked as learning.
- Concepts dressed up as skills. "OOP", "Data Structures", "SDLC", "Agile". For an experienced engineer these are assumed. For freshers they're common and only slightly useful; one line is plenty.
- Long version lists. "Java 8, Java 11, Java 17" is one skill. So is "React 16, React 18".
- Twenty items in one line. A wall of keywords reads as stuffing. If you genuinely have broad experience, the grouping above handles it.
Freshers: what if your list is short?
Then it's short. A fresher with "Java, Python, SQL, Git, React" and one solid project using each of them is in a better position than one with thirty technologies and no evidence.
If you're coming from a tier-2 or tier-3 college and worried that the list looks thin next to someone from a bigger campus, the answer is projects. A longer list won't help. One project that uses three of your listed skills properly, with a GitHub link, is what convinces a reviewer. Our post on the resume for freshers has more on structuring a first resume.
A "currently learning" line is fine if it's true and relevant: "Currently learning: Go, through a rate limiter project on GitHub". It shows direction without claiming competence you don't have yet.
Contested: should you list skills only in the skills section?
Some recruiters prefer skills woven only through the experience section, with no separate list. Others, particularly those screening high volumes, want the list so they can check fit quickly.
I'd keep a short section. It helps the quick scan and the keyword match, and costs four lines. The rule is just that nothing in it should be unsupported elsewhere.
A quick check before you send
Read your skills section aloud and, for each item, ask whether you could answer three follow-up questions on it right now. If not, cut it or move it to "learning". Then compare the top of each line against the posting you're applying to.
If you want a second opinion on the whole resume, the free resume score checks it from a PDF upload, no account needed.