Resume keywords for software engineers (and how to back them up)

The keywords that matter for a software engineer are the ones in the posting you are about to answer, in the order that posting gives them, and not the forty-technology lists a search turns up. A generic list cannot tell you whether this team cares more about Terraform than about TypeScript, and that difference decides what your first three bullets should say.

Where the keywords are in a posting

Engineering postings are unusually structured: a list of responsibilities and a list of requirements, usually separated, often repeating the same technology in both. Read them as two different signals. The requirements list is what the screening step looks for. The responsibilities list is what the hiring manager wants done, and it is where the seniority language lives — "own", "lead", "design", "review", "mentor". A term that appears in both is a term worth a bullet of its own.

Words that repeat

Mark every technology, practice and domain word that appears more than once. Repetition is the closest thing a posting has to emphasis. If Kafka shows up in the stack line, in a responsibility ("own the event pipeline") and in a requirement ("experience with streaming platforms"), the team is telling you where the work is.

The same pass should catch words that are not technologies at all: "multi-tenant", "payments", "on-call", "migration", "data residency". For a senior role these often carry more weight than another framework, because they describe the shape of the problem rather than a tool.

The stack line is a hint, not a requirement

Most postings include a line like "our stack: TypeScript, React, Node, Postgres, AWS". That describes what the team uses today, not a checklist of what you must already know, and treating it as one leads people to add tools they have read about but never shipped. Read it instead as a map of where to look in your own history: if the stack line says Postgres and your resume says "database work", you have a vocabulary mismatch to fix. If it says Rust and you have never written Rust, it has told you something useful too — this is a team where you would be learning, and the honest version of your application says so.

Required vs preferred for engineers

Postings usually separate "you have" from "nice to have". The distinction is not decoration: read required terms as the gate and preferred terms as the tie-breaker. Every required term you genuinely have should be visible without the reader hunting — in a bullet, in the skills line, or both. Preferred terms are worth one mention if you have real work behind them, and nothing at all if you do not.

Kubernetes and k8s are the same word to a human, and the same goes for "Postgres" and "PostgreSQL", "GCP" and "Google Cloud". A good keyword check treats them as one term. A recruiter's search may not: Greenhouse's keyword filter matches exactly, so write the full name once next to the abbreviation, "Kubernetes (k8s)", and move on; see how ATS keyword matching works. What does not count is a synonym for something you have never used: calling a MySQL migration "database architecture" does not make it Postgres experience.

Skills section vs bullets

Engineers tend to over-invest in the skills section because it is easy to edit and looks impressive when it is long. Read it as an index, not as evidence: its job is to let someone confirm a term in two seconds, then find the bullet that proves it.

That gives a simple rule, and it runs both ways. Every skill in the list should appear in the body of the CV, in a role where you used it; every technology you used heavily should appear in a bullet, not only in the list. A technology mentioned only in the skills line is invisible in the part of the page people actually read.

Two shapes work:

• Grouped by kind, short. "Languages: TypeScript, Python, Go. Infrastructure: AWS, Kubernetes, Terraform. Data: PostgreSQL, Redis, Kafka." Three lines, everything filterable, nothing invented.
• In the bullets only. No skills section at all, with each technology appearing in the role where you used it. Stronger evidence, harder to scan, common among senior candidates with a focused history.

What does not work: a wall of logos, a "proficiency" scale with no definition, or the same technology listed three times to look deeper. None of these gives a reader anything to verify.

Seniority signals

For engineering roles, the words that separate a mid-level CV from a senior one are rarely new technologies. They are the verbs and the scale: owned, led, designed, migrated, mentored, operated, on-call, reviewed. Compare two true sentences about the same job:

• "Worked on the payments service and helped with the migration to Kubernetes."
• "Led the migration of the payments service to Kubernetes over two quarters, including the rollback plan and the on-call runbook."

Both describe the same work. The second names the scope (two quarters), the ownership (led), the risk (rollback plan) and the operational side (runbook) — all of which a senior posting is asking about. It does not invent a title or a metric. It chooses which true things to foreground. On-call is worth naming explicitly when you did it, because a posting that asks for it is looking for the word, and a CV that hides it loses the match; Google's SRE book chapter on being on-call is a useful check that you are describing the practice as teams actually run it.

Design reviews and mentoring are the other two signals senior postings ask for and CVs routinely omit. If you led a review, name what was decided, not just that you attended. If you mentored, name what the person can now do. And do not borrow the vocabulary: "led", "owned" and "architected" are the words an interviewer will ask you to unpack. "Maintained the billing service for a year, including its on-call rotation, and wrote the runbook the team still uses" reads better than a borrowed "owned".

A worked example

The posting below is invented, but it is the shape of a real backend job ad. The candidate — Daniel, four years of experience, applying in Berlin — is invented too.

Backend Engineer, Payments (fictional)

You will own our settlement service, which processes about 4 million transactions a day. You will work with PostgreSQL, Go and Kafka, and you will be on the primary on-call rotation. We are looking for someone who has operated a production service and can explain a performance problem from first principles. Experience with Terraform is a plus.

A first pass at the keyword map:

Daniel's original bullet, and the version aimed at this posting:

daniel-cv-2026.pdf

Worked on the settlement service and improved database performance.

cv['backend engineer, payments']

Cut the nightly reconciliation job on the settlement service (about 1.5 million transactions a day) from 40 minutes to 6 by rewriting the query after reading its EXPLAIN plan. Primary on-call for the same service for nine months.

Four things changed and nothing was added. The vague "database performance" became the specific job and its measured improvement. The scale of the service, which was on file but not on the CV, now appears. The on-call rotation, which the posting requires, is named. And "reading its EXPLAIN plan" answers the posting's "first principles" line without claiming anything new — if an interviewer asks, PostgreSQL's guide to EXPLAIN is clear that cost estimates are arbitrary units while EXPLAIN ANALYZE reports real milliseconds.

Terraform stays off the CV. Daniel has not used it, the posting calls it a plus, and one invented line would put the whole application at risk in the first technical conversation.

The skills line for the same application

Skills: Go, PostgreSQL, Kafka, Redis, Kubernetes, gRPC. Service ownership, on-call, incident response, query performance.

Six technologies and four practices, each of which appears in a bullet somewhere on his CV — nothing from the posting that Daniel cannot defend, and nothing generic like "team player" that the bullets already demonstrate.

Checking coverage

Once the CV is rewritten, check it against the posting rather than against your memory of the posting. Read the posting again, list its terms, and mark each one: present, present under another name, or absent. cv[0] does that pass mechanically. Paste the description and it lists the required, preferred and nice-to-have terms your CV genuinely contains, and the ones it does not; variants and acronyms count, so "k8s" and "Kubernetes" are one term. The check needs a free account — there is no public no-signup version — and the free plan includes fifteen checks a month.

What it does not do is score you. There is no number that means "good", because the number would be invented: a term count cannot tell you whether a hiring manager cares more about Kafka or about the domain, and it cannot see the rest of the applicant pool. Resume keywords and ATS matching goes into why a match count is a text comparison rather than a prediction.

The useful output is the list of gaps, and the useful response depends on the gap:

• You have the work under another name. Fix the wording, not the history. This is the majority of gaps.
• You have adjacent work. Say what it actually was and let the reader judge. "Built the event pipeline on RabbitMQ" is honest and often close enough for a Kafka team.
• You have none of it. Leave the gap visible. A required term you cannot discuss is worse than a missing term, because the interview will find it in the first ten minutes.

Coverage is a floor, not a forecast. A CV that names every required term is eligible for a human read; it is not more likely to be hired than a clearer CV with one honest gap. The two pages still have to be readable, the bullets still have to be true, and the interview still decides. If you want the whole method rather than the engineering version, tailoring your resume to a job description walks through the same five steps, and writing a cover letter from your resume shows how to carry two of these keywords into the letter without repeating the CV.

When you are ready to check your own CV against a real posting, start with your CV at cv[0]: one base history, a keyword check per job, and a tailored version you can defend line by line.