Tech Resume Keywords: What Recruiters Actually Search For

Technical hiring searches differently

Most advice about resume terms assumes a recruiter reads job titles and matches them against a role. In technical hiring that is not what happens first.

A technical recruiter with two hundred applications runs a search. Not a reading pass, a search: a query against the applicant pool for the two or three things the hiring manager said were non-negotiable. Kafka. Terraform. Swift. Whatever the team cannot train someone into in a fortnight.

That changes what belongs on the page. In a marketing resume, phrasing matters because a person is reading. In a tech resume, exact strings matter first, because a query is running, and phrasing matters second, when the ten survivors get read properly.

Both passes are real and they reward different things. The rest of this is about satisfying the first without wrecking the second.

Name the stack the way the industry names it

The most common failure is imprecision that reads as fine to a human and matches nothing.

"Cloud infrastructure" does not match a search for AWS. "Containerisation" does not match Kubernetes. "JavaScript frameworks" does not match React. "Database experience" does not match Postgres. In each pair the vaguer term is what a candidate writes when they are trying to sound broad, and it is invisible to the search that decides whether they get read.

Write the specific name. Then, if breadth is genuinely part of your value, add the general term alongside it rather than instead of it.

Variants matter as much as the base term. React and React Native are searched separately and mean different jobs. Postgres and MySQL are not interchangeable to a team that runs one of them. Node and JavaScript are not the same claim. Python and PyTorch answer different questions.

Spelling and casing are worth a minute. Postgres, PostgreSQL, Node.js, .NET, C#, CI/CD. Search tools vary in how forgiving they are, and where they are not forgiving you simply do not appear.

Where the terms should sit

A skills list gets you through the search. It does not get you through the read.

The moment a person opens your resume, a skills section becomes the least trusted part of it, because anyone can type anything there. What they trust is a tool named inside a sentence about work you did, with an outcome attached.

Compare two ways of claiming the same thing. A skills line containing "Kubernetes" tells a reviewer you have heard of it. A bullet reading "moved twelve services from EC2 to Kubernetes, cutting deploy time from forty minutes to six" tells them you have run it in anger, at what scale, and to what end.

So the useful pattern is both, deliberately. The skills section carries the full set of terms for the search. The experience bullets carry the eight or ten that matter most, embedded in evidence. Anything in the skills section that never appears in the experience is implicitly a weaker claim, and experienced reviewers read it that way.

One clear takeaway: the search finds your skills list, the human believes your bullets.

The skills section that stops working

There is a length past which a skills section damages you.

Roughly fifteen items is the ceiling. A list of forty tools does not read as broad capability, it reads as a list of everything the candidate has ever installed. Nobody is current in forty tools, the reviewer knows it, and the section stops carrying information because there is no way to tell which four you would be trusted with on Monday.

Cutting it is uncomfortable and it improves the document. Drop the things you used once four years ago. Drop the ones that are implied by something else you listed, since Git and Jira tell a reviewer nothing about you. Drop the ones you would not want to be interviewed on, because listing them is an invitation.

Group what survives. Languages, frameworks, infrastructure, data. Grouped lists are read; long comma runs are skimmed and forgotten.

Our guide to resume keywords covers the general principles here. The tech-specific part is that your list will be checked by someone who knows these tools, which raises the cost of padding it.

Seniority is a keyword problem too

Technical resumes tend to be precise about tools and vague about scope, which costs candidates the level they are placed at.

Two engineers can list identical stacks. What separates a mid-level resume from a senior one is the verbs. Built and implemented describe someone executing a defined task. Designed, owned, migrated, led and set describe someone deciding what the task is.

Those words are searched for as well, particularly by recruiters filling senior roles who need evidence of scope before they will pass a profile to a hiring manager. If your work included architecture decisions, on-call ownership, mentoring or the technical direction of a project, the resume needs to say so in those terms rather than leaving it to be inferred.

Numbers do the same job. Requests per second, data volume, team size, number of services, uptime. Scale is what turns a familiar-sounding claim into a specific one, and it is the fastest way to signal the difference between a side project and production ownership.

Reading the job description properly

Tech job descriptions are usually written by the hiring manager and they leak more information than most.

Read the requirements in the order they are written, because that order tends to reflect actual priority rather than a template. The first two or three technical requirements are what the team is short of. The rest is a wish list assembled from the team's collective skills.

Distinguish the hard filters from the soft ones. A specific language, a specific cloud, a domain like payments or medical devices, a compliance regime like SOC 2 or HIPAA. Those tend to be genuine. General phrases about collaboration and fast-paced environments are not filters and are not worth mirroring.

Then check what you honestly have and put those terms where they will be found. Where you have adjacent experience rather than the exact thing, name the adjacency directly: GCP rather than AWS, Vue rather than React. A reviewer can evaluate a stated adjacency. They cannot evaluate a silence, and they will not guess in your favour.

Doing this per application takes ten minutes. Our resume builder handles the mechanical part of it, comparing your resume against a specific posting and showing which required terms are missing.

What not to do

A few tactics circulate in technical communities and are worth naming as bad ideas.

• White text keyword stuffing. Parsers strip formatting, so the hidden block appears in the extracted text a human reads. It is discovered often and it ends the application.
• Listing tools you cannot discuss. Technical interviews start from the resume. Every term on it is a question you have volunteered to answer.
• Proficiency bars and star ratings. They convey nothing, four stars in Python means nothing shared, and they take space that a bullet with a number could use.
• Copying the job description verbatim. It reads as copied, and hiring managers who wrote the posting recognise their own sentences immediately.
• Alphabetising the skills list. Order by relevance to the role. The first four items are the only ones read closely.

Non-engineering technical roles

Everything above is written from a software engineering angle, and the same mechanics apply across the rest of technical hiring with a different vocabulary.

Data roles are searched on the boundary between tools and methods. SQL, dbt, Airflow and Snowflake on one side, experimentation, forecasting and causal inference on the other. Analysts who list only tools get filtered towards reporting work; analysts who list only methods do not appear in the search at all.

Security roles are searched on frameworks and controls as much as products. SIEM, SOC 2, ISO 27001, threat modelling, incident response. Naming the product you used without the framework it served leaves out the half a hiring manager cares about.

Platform and infrastructure roles are searched on the specific pieces rather than the category. Terraform, Ansible, Datadog, Kubernetes, the cloud by name. "DevOps" as a standalone term matches almost nothing useful because everybody claims it.

Technical product and program roles are the hardest, because the terms that matter are half technical and half process. Naming the systems you worked on, in the same words the engineers used, is what separates a credible technical product resume from a generic one.

Whatever the discipline, the test is the same. Take the two or three things this team cannot hire around, and check that your resume contains those exact words, inside a sentence about work you actually did.

Questions people ask

How many technical skills should a resume list?

Around ten to fifteen, grouped by type. Longer lists stop being credible because no one is current in that many tools, and the reviewer cannot tell which ones you would actually be trusted with.

Should I list a language I used only once?

Only if you would be comfortable being interviewed on it. Everything on a technical resume is a question you have invited, and a weak answer costs more than the listing gained.

Do keywords matter more than projects?

They decide different stages. Keywords get you into the pile that gets read. Projects and outcomes decide whether you leave that pile with an interview.

Should I tailor a tech resume for every application?

Change the top few skills and the order of your bullets to match the posting's first three requirements. That covers most of the benefit in about ten minutes.

Do recruiters really search by exact tool names?

Yes, most commonly for the two or three things the team cannot train someone into quickly. Vaguer category words do not match those searches.

Related reading

• Healthcare Resume Keywords: Licences, Settings and Systems
• Cold Messages to Hiring Managers That Get Replies