What technical skills to put on a resume when your real value is more than a keyword list

If you are wondering what to write in the skills section of a resume, the tempting answer is everything. Python, React, SQL, Docker, Kubernetes, AWS, Azure, Terraform, Kafka, Git, Linux, Agile, and Excel because why not. Each addition feels safe, because surely more keywords means more matches.

It works the other way round. After a decade in technical work you have touched a lot of tools, and listing all of them makes your CV read like a keyword drawer with a career attached. The skills section has one job. It should let the reader work out, in a few seconds, what kind of work you can credibly do. A memory dump fails at exactly that.

Your skills section has three different readers

It helps to know who you are actually writing this list for, because there are three of them and they want different things.

The recruiter gives it a few seconds of scanning to check you roughly match the brief. The applicant tracking system matches your wording against the advert, so the right terms genuinely need to appear somewhere as plain text. And the hiring manager, the one reader with real technical judgment, uses it to price your credibility. They know what a coherent skill set for this role looks like, and they notice when a list smells like padding.

The bloated list fails all three at once. The recruiter cannot find the signal, the ATS matches you to the wrong things, and the hiring manager starts wondering how much of the list is real. One skill you clearly cannot defend quietly taxes the credibility of every skill sitting next to it.

Start with the job, not your toolbox

The right skills depend on the role in front of you, which is the same logic behind tailoring your CV to a job description. A senior backend role cares about distributed systems, databases, cloud infrastructure, observability, and performance. A data engineering role cares about pipelines, orchestration, modelling, and warehouses. An AI product role cares about LLM workflows, evaluation, retrieval, and product judgment.

Same person, different emphasis. So before touching the skills section, read the advert and mark the skills they repeat, the tools that look essential, the concepts that define the work, and the nice-to-haves you genuinely have.

Then mark one more category honestly. The skills you technically have but could not discuss in an interview without squirming. Those are the dangerous ones, and they do not belong near the top of your CV no matter how well they match the advert.

Group skills so a human can scan them

A random wall of tools is hard to read even when every item in it is true. Grouping fixes that cheaply:

• Languages: Python, TypeScript, SQL
• Backend: FastAPI, Node.js, REST APIs, event-driven systems
• Data: PostgreSQL, dbt, BigQuery, Airflow
• Cloud and infrastructure: AWS, Docker, Terraform, CI/CD
• Practices: observability, incident response, technical mentoring

This is not decoration. It reduces the reader’s effort, which is the closest thing a CV has to a universal currency. A recruiter can scan it, a hiring manager can see the shape of your experience, and an ATS can still find every word it is looking for. The Prospects technical CV example makes the same point in a duller way. Technical depth lands best when the structure stays easy to scan.

The list makes claims. The bullets pay for them.

A skills section is a set of promises, and promises are cheap. The reader believes the ones your experience section actually pays for.

If Kubernetes is in your list, somewhere in your bullets there should be work that obviously involved it. If you list machine learning, the reader should be able to tell whether you trained models, shipped model-backed features, maintained pipelines, or completed a course three years ago, because those are four very different claims wearing the same keyword.

The weak version keeps everything at the level of the claim. “Skilled in cloud architecture, microservices, and DevOps” could be written by anyone, including people it is not true of. Compare it with a bullet like “Reworked the deployment pipeline for a microservices platform on AWS, reducing failed releases by tightening environment checks and rollback steps.” The second one gives the skill a real job to do, and the reader can feel the difference immediately.

The strongest CVs run this loop deliberately. The important skills appear once as a signpost in the list and once as evidence in a role or project. Anything that only exists in the list starts to look ornamental.

Cut stale and decorative skills

This part is oddly painful, because skills carry sentiment. A tool stays on the CV because it used to matter, or because you were proud of learning it, or because deleting it feels like losing a version of yourself that worked hard.

But a CV is not an archive, and the reader is not grading your past effort. If a skill is old, shallow, or likely to distract from the role you want now, cut it or push it down. The document exists to make the strongest case for this job, not to preserve every technology that ever passed through your hands.

For senior people the stakes are higher than they look. A huge undifferentiated list actively reads as junior, because it suggests you cannot tell which of your own skills matter. Seniority shows up as judgment, scope, and tradeoffs. Forty-three technologies in a row signals the opposite of all three.

What I would put on a technical CV

For most technical roles, the list earns its place when it contains core languages you can actually work in, frameworks and platforms relevant to this job, cloud or data or infrastructure tools you have used in real delivery, practices that show how you operate, such as testing, observability, incident response, or mentoring, and domain knowledge where it matters, such as fintech, healthtech, or developer tools.

And I would leave out basic office tools unless the role genuinely cares, methodologies you have only heard of, anything you used once in a tutorial, vague soft skills with no proof attached, and the job advert pasted back at itself. The goal is not to impress everyone. It is to make the right reader think this person fits the work we need done.

Where OutRung helps

Choosing the right subset of your skills for every single application is exactly the kind of job-search admin that gets tedious fast, which is why most people give up and keep one bloated list forever.

The way OutRung approaches it is to keep one master profile holding the full, honest version of your experience. When a role comes along, you can score the match, see which skills that specific job actually cares about, and generate a tailored CV that pulls the relevant evidence forward and leaves the rest in the profile where it belongs. Even broad careers guidance on what skills employers want ends up separating job-specific hard skills from everything else, which is another way of saying the list has to stay selective.

The honesty rule still applies with tooling in the loop. A tool can organise and tailor. It should never promote a passing familiarity into a core capability, because you are the one who has to defend the list in the interview.

A final rule

A technical skill earns its line when three things are true. You have used it enough to discuss it. It matters for this role. You can point to evidence somewhere else on the page.

If it fails one of those tests, think hard before including it. A shorter, sharper skills section beats a long one that leaves the reader wondering what is real, because once they start wondering, they wonder about everything.