The skills section of a developer resume is often the longest and the least read. It piles up everything the candidate has ever touched: three languages seen in class, a framework tried over a weekend, a database installed for a tutorial. The recruiter is looking for two simple pieces of information: the stack you have really mastered, and proof that you have used it in a real context. This article explains how to move from an inventory to a section that serves your application, from the first keyword filter all the way to the technical interview.
Why a list of twenty technologies works against you
A long list starts from a good intention: not missing a single keyword. Yet it produces the opposite effect on the two successive readers of your resume.
The first is the recruiter or talent acquisition specialist, who often screens dozens of applications for the same position. They compare your page to the job ad, look for the three or four essential technologies and check that these appear somewhere other than in the list. When Java, Python, Go, Rust, C#, PHP and TypeScript follow one another with no hierarchy, they cannot tell which one is your main language. They may put you in the pile of scattered profiles or, worse, call you back for a Go position when you have only written a few hundred lines in that language.
The second reader is the tech lead or the developer who will run the interview. They take the list literally. Every technology you list becomes a potential question: "You put Kafka, how did you handle failing consumers?" A skill you cannot defend for five minutes weakens all the others. A candidate who admits "I only used it in read mode" on three lines of their section loses credibility, even if they are excellent on everything else.
Finally, there is a signalling effect. An experienced profile is recognisable precisely by its ability to choose. A tight section, which owns a main stack and a few complements, reads like the work of someone who knows their worth. The Onisep job profile for the software developer 🔗 makes the same point: the job is about designing and evolving applications, not collecting tools.
Group your stack by use rather than alphabetically
Alphabetical order is the worst possible order: it puts Angular before TypeScript and Ansible before Kubernetes, and says nothing about your profile. Instead, group your technologies by use, in the order in which a feature passes through them.
An organisation that works for most profiles:
- Languages: the ones you write every week, from most used to least used;
- Frameworks and libraries: on the interface side, the server side and the data side;
- Data: relational databases, key-value stores, message queues, warehouses;
- Infrastructure and delivery: containers, cloud, continuous integration, monitoring;
- Practices: automated testing, code review, API design, accessibility, observability.
Four or five lines are enough. A backend developer does not need an "interface" line if they have never shipped a screen to production. Conversely, a front-end developer benefits from detailing the "practices" line (web performance, accessibility, design system), because that is where the difference between two React profiles lies.
Here is the section of a backend developer before and after grouping.
Before: "Skills: Agile, Angular, AWS, Docker, Git, Java, JavaScript, Jenkins, Jira, Kafka, Kotlin, Kubernetes, Linux, MongoDB, MySQL, Node.js, PostgreSQL, Python, React, Redis, Spring Boot, SQL, Terraform."
After:
- Languages: Kotlin, Java, SQL; Python for scripting
- Server: Spring Boot, REST APIs documented with OpenAPI
- Data: PostgreSQL (data modelling, query optimisation), Redis, Kafka
- Delivery: Docker, GitHub Actions, deployment on Kubernetes managed by the platform team
- Practices: integration tests with Testcontainers, code review, observability
The second block contains fewer words, but the reader immediately knows what the core of the profile is and what is a complement. Angular, React and MongoDB have disappeared: the candidate had come across them without ever using them for long. The backend developer resume template applies exactly this principle, in only two lines.
Show a level without progress bars
Progress bars, stars and mastery percentages should be banned. They rest on no shared scale: your "four stars out of five" in Python means nothing to a reader who does not know your reference point. They also raise a technical issue, because many recruitment tools extract graphic elements poorly, and the information simply disappears.
Three more useful ways to convey a level:
- The position in the line. The first technology listed is the main one. This simple ordering conveys the essentials without a single extra word.
- A usage detail in brackets. "PostgreSQL (data modelling, query optimisation)" says more than "advanced PostgreSQL". "Kubernetes (deploying applications on an existing cluster)" is more honest and more reassuring than a bare Kubernetes, which the lead will associate with cluster administration.
- A duration or a context. "Go, used for a year on two internal services" pins down your level precisely without overstating it.
For languages, keep the usual markers (native, fluent, professional) and tie English to a real use: documentation, code reviews, meetings with a team abroad. It is a screening criterion in many product teams.
Finally, avoid absolute qualifiers, "expert" first among them. They invite the hardest question of the interview and bring you nothing at the first screening.
Link each technology to an experience on the resume
The skills section is only an index. The proof lies in the experience section, and a good developer resume lets the reader move from one to the other effortlessly: every important technology in the section reappears in at least one experience or project bullet.
In practice, reread your section line by line and ask yourself one question for each technology: in which job did I use it, and to produce what? Three cases arise.
- You find a bullet that shows it. Perfect. Check that the bullet names the technology and describes a deliverable: "Rewrote the discount calculation in Kotlin, with integration tests on PostgreSQL" rather than "Backend development".
- You used it, but no bullet mentions it. Add it to the context line of the job ("Team of 6 developers, Kotlin / Spring Boot / PostgreSQL on AWS") or to an existing bullet.
- You cannot find it anywhere. It is probably a technology you only skimmed. Remove it, or move it to a more modest mention ("basics", "personal project").
This work pays off directly in the interview. A lead who asks you about a technology on the list will find in your experience the context in which you used it, and you will be able to tell a precise story rather than recite a definition. TechCV resume templates, such as the full-stack developer one, follow this logic: the context line of each job gives the stack, and the bullets put it to work.
Adapt the section to each job ad
A well-presented stack is not set in stone. It adjusts to each application, without lying, by playing on order and level of detail.
Reuse the exact words of the job ad. If the ad says "Node.js", do not write "Node". If it mentions "TypeScript", do not settle for "JavaScript". Screening software compares character strings, and so do non-technical recruiters. A keyword present in your background but missing from the section is a missed opportunity.
Reorder the lines. For a data-oriented position, the "Data" line moves to the top. For a platform team, the "Infrastructure and delivery" line takes first place and is detailed further.
Expand one line, shrink the others. If the ad insists on testing, add the matching tools and practices (contract tests, end-to-end tests, coverage tracked in continuous integration) and tighten the rest to stay on one page.
Do not copy a technology you have never practised. The temptation is strong when the ad lists it first. Prefer an honest wording in the summary ("comfortable in Java, currently ramping up on Go"): a lead values a clear-sighted candidate far more than an awkward discovery during the interview.
The same logic applies to the two lines that open the resume: our article on the title and summary of a tech resume shows how to place your main stack there, and the one on scale-ups’ ATS explains how to write technology names so they are found.
The content of the section changes from one ad to the next, but its layout must remain flawless. An editor such as TechCV’s keeps the layout stable while you reorder your lines, and produces a PDF whose text remains selectable: screening software then reads your skills in the right order, instead of mixing them up as it often does with column-based resumes. You can start from your current resume and rework it directly in the resume editor.
Frequently asked questions
How many technologies should a developer resume list?
There is no magic number, but a section of four or five lines grouped by use, with about a dozen technologies in total, covers most profiles. Beyond that, check that each added item matches an experience you can talk about.
Should I mention Git, Jira or Agile?
Git is expected from any developer: listing it does not set you apart, but its absence may surprise screening software. Put it in the "delivery" line. Jira and "Agile" add little; describe your way of working in the experience section instead (sprints, code reviews, frequent production releases).
How do I present a technology I learned on my own?
Like the others, but with its context: "Rust (personal command-line tool project, published on GitHub)". The recruiter then knows the skill is real without mistaking it for professional practice.
Do soft skills belong in the skills section?
Not as a list of adjectives. Team practices (code review, documentation, mentoring apprentices) prove your way of working far better, and they belong in the "practices" line or in the experience bullets.