"Use the words in the job description" is correct advice, but it isn't a method. Taken literally, it ends with a wall of buzzwords pasted under Skills and no change in callbacks. Below is a repeatable workflow: pull out the right terms, rank them, place them where your experience proves them, and stop before it turns into keyword soup. After a couple of tries it takes 15–20 minutes per application.
What matching is for
Apply on a company's careers page and your resume usually lands in an applicant tracking system that extracts the text and lets recruiters search and filter. Someone hiring a backend engineer may search "Go," "Kubernetes" or "distributed systems." If you have those skills but describe them differently, or hide them in a paragraph, you're harder to find. The goal is to be findable for what you can genuinely do, not to game software.
That assumes your text extracts cleanly. If you're unsure, this breakdown of what ATS parsers read and what breaks them covers headings, dates, columns and file types.
Pass 1 and pass 2 over the posting
First read for meaning: will this person build APIs, run infrastructure, or ship UI? Then read for terms, sorted into four groups:
| Group | Backend examples |
|---|---|
| Title | Backend Engineer, SDE-2 |
| Tools and skills | Go, PostgreSQL, Kafka, Kubernetes, AWS, gRPC |
| Practices | code review, CI/CD, observability, on-call |
| Context | payments, high-throughput, B2B SaaS |
Notice where each term sits. The title, the opening paragraph and the "Requirements" list outweigh "Nice to have."
Rank them
Split the terms into must-have (title, required skills, anything repeated, usually 5–10) and nice-to-have (another 5–10). A term that shows up in the title, the summary and the requirements is almost certainly a must-have.
Audit your resume
Mark each term with one of four labels:
- Present in the employer's wording
- Reworded: "Postgres" vs "PostgreSQL," "K8s" vs "Kubernetes"
- True but missing: you did it and never wrote it down
- Not true: you don't have this skill
Edit only the reworded and true-but-missing items. The "not true" list is information, not a to-do list.
A quick script speeds up the first pass:
import re
jd = open("jd.txt").read().lower()
cv = open("resume.txt").read().lower()
terms = ["go", "postgresql", "kafka", "kubernetes", "aws", "grpc", "ci/cd", "observability"]
for t in terms:
n_jd = len(re.findall(r"\b" + re.escape(t) + r"\b", jd))
n_cv = len(re.findall(r"\b" + re.escape(t) + r"\b", cv))
print(("OK " if n_cv else "MISSING"), t, "JD:", n_jd, "CV:", n_cv)
It won't know that Postgres and PostgreSQL are the same, but the gaps stand out. Make resume.txt by copying all the text out of your PDF, which also confirms the PDF contains real text.
Place each term where the evidence lives
A keyword is strongest when it appears twice: once in Skills, where it's searchable, and once in a bullet, where it's believable. Reorder Skills so the must-haves come first without deleting the rest. Then rewrite one or two bullets per relevant role.
Before: Worked on backend services for the payments team.
After: Built and maintained Go services for payment reconciliation on PostgreSQL; added tracing and dashboards that cut time-to-diagnose for on-call issues.
That bullet covers Go, PostgreSQL, payments and observability because that was the actual work. If you can't stand behind a result, describe the work and skip the result. And if the posting says "Backend Engineer" while your summary says "Full-stack developer," lead with backend if that's truly your strength.
Mirror their wording once, then stop
Write "CI/CD" at least once if that's their term. Once in Skills plus once or twice in context is enough. Warning signs that you've gone too far: 40 items under Skills, the same word in every bullet, tools you've only read about, or a section that reads aloud like a tag cloud. Interviewers ask about every line.
Frontend example
Posting: Frontend Engineer, strong React and TypeScript, building our design system; accessibility (WCAG), Jest and Playwright testing, performance work required; Next.js a plus.
Audit: React and TypeScript present. "Component library" should also be called "design system." Accessibility is true but missing (you fixed keyboard navigation). Playwright isn't true, since you used Cypress, so list Cypress.
Built a shared React + TypeScript component library (internal design system) used across three product teams; added keyboard navigation and ARIA labels to meet WCAG guidelines, with Jest and Cypress tests.
Speeding up the comparison
Doing it by hand is the most reliable approach, because you decide what's true. Tools can speed up the comparison. Imperfectors, which I'm building, includes job-description keyword matching on its ₹499/month Pro plan: paste a JD and see matched and missing keywords. The resume builder itself is free. Treat any tool's output as a checklist, never a verdict.
Akshay Arora builds Imperfectors, a free ATS-friendly resume builder.
Top comments (1)
The four-way audit is a useful guardrail, especially the “not true” bucket: it keeps keyword matching from turning into claims you cannot defend in an interview. I’d pair the “true but missing” items with a small evidence note—project, action, and result—so a restored keyword leads to a specific bullet rather than just a skills-list mention. How do you decide when a synonym such as “K8s” versus “Kubernetes” is worth adding without making the resume feel repetitive?