cvharbor editorial

Keyword matching for technical and engineering resumes

A resume that lists "JavaScript" when the role needs "React" fails a search it should have passed. Technical hiring runs on tool names, version ranges and category distinctions that generic keyword advice does not cover.

Most keyword advice stops at "match the job description." For a technical role that is not specific enough to act on. A recruiter sourcing engineers is not scanning for the word "programming" — they are typing a Boolean string with named tools, and a resume that lists the right category but the wrong specific tool inside it does not match, even though a human reading both would call them equivalent.

Key Takeaways

• Technical recruiters search for specific tools and frameworks, not the general skill category they belong to — "Terraform" is not found by a search for "infrastructure as code".
• A language is not its frameworks. Listing "JavaScript" does not surface a resume for a React role, and listing "React" does not surface it for a plain Node.js role.
• Version numbers matter for some searches (a Python 2 to 3 migration, a specific Kubernetes API version) and are noise for most others — include them only where the gap is real.
• A skills section grouped by category (languages, frameworks, infrastructure, data) is easier to scan and search than one long undifferentiated list.
• Proficiency adjectives ("expert", "proficient") are not searchable in most ATS products and do not substitute for evidence of use.

Why "match the job description" is not enough here

A non-technical recruiter searching for a nurse types "registered nurse" or "RN" — there are two forms of one term, and covering both is the whole job. A technical recruiter sourcing a backend engineer might search "Go" AND "Kubernetes" AND "gRPC" AND NOT "junior", stacking four or five specific, unrelated terms in one query. There is no single phrase to cover. The resume has to actually contain the tools, plural, that the role uses.

This is also why summarising a stack as "modern cloud infrastructure" fails silently. It reads well and matches nothing. The recruiter's search terms are the proper nouns: AWS, not "cloud"; PostgreSQL, not "databases"; Datadog, not "monitoring tools". Write the noun the recruiter typed, not the category it belongs to.

Tool versus category versus language

These three are not interchangeable, and conflating them is the single most common technical resume mistake.

• Language: the base language you write in — Python, Java, TypeScript, Go. This is necessary but rarely sufficient on its own for a search.
• Framework or library: what you build with the language — Django or FastAPI for Python; Spring Boot for Java; React or Next.js for TypeScript. A role advertised as "React developer" is searched by that name, not "JavaScript developer".
• Category: the general term a job description might use in prose but a recruiter rarely searches directly — "frontend", "infrastructure as code", "observability". These describe the work; they are not the tool.

The second version is not wrong as prose — it is an accurate summary. It is simply not what gets found. A resume can, and often should, use both: the category to give a reader context in a sentence, and the named tools in a skills list a search actually indexes.

When version numbers matter

Most of the time, a version number adds nothing a recruiter searches for. Nobody sources for "React 18" as opposed to "React". Adding one in that case just narrows a match that did not need narrowing.

It matters in a smaller set of real cases: where a major version marks a genuine break in the skill. Python 2 to 3 changed enough that some job descriptions specify it. Angular 1 (AngularJS) and Angular 2+ are different enough in practice that recruiters searching one do not expect the other. Java 8 versus Java 17+ tracks a real language-feature and hiring-market split in some companies. Kubernetes API versions matter for someone hiring specifically around a deprecation. If the version marks a real distinction the job market makes, include it. If it does not, drop it — it costs nothing to omit and adds nothing to include.

Grouping a skills section so it is actually searchable

An unstructured list of fifteen tools in one line is technically searchable but hard for a human to scan once they open the resume, and scanning is what happens after the search succeeds. Group by category with the specific tools inside each — this keeps the searchable terms while giving a reader instant orientation.

• Languages: the base languages, in rough order of proficiency or recency.
• Frameworks & libraries: named separately from languages, since they are searched separately.
• Infrastructure & tools: cloud provider, orchestration, CI/CD, IaC tools — named specifically (AWS, not "cloud"; GitHub Actions, not "CI/CD pipelines").
• Data & storage: specific databases and data stores, not "databases" as a category.

Our builder groups your skills automatically and flags when a tool is mentioned in a role description but missing from your skills section. Check your CV

Where the tool name actually belongs

A skills section gets a tool found. A bullet point in a work-experience entry gets it believed. "Migrated a monolith to microservices using Kubernetes and gRPC, reducing deployment time from 40 minutes to 6" contains the same searchable terms as a skills list but also shows the tool applied to a real outcome — which is what a human reader is actually screening for once the search has already worked.

Put the tool in both places when it is a tool you actually used at depth: once in the skills list for search coverage, and again inside the specific project or role bullet where it did something. A tool mentioned only once, buried in a paragraph describing five other things, is easy for a fast reader to miss even though it technically appears.

Do not list what you do not want to be asked about

Adding a tool purely because the job description mentions it, when you have touched it once in a tutorial, works exactly as intended: it gets the resume found and gets you into an interview where the first technical question exposes the gap. Technical interviewers ask about listed tools specifically because the list is the interview's starting point. A shorter, accurate list outperforms a longer, hopeful one at the interview stage even when it underperforms it at the search stage.