How to tailor a resume to a job description

Start by extracting the real rubric

Every job posting contains two documents layered on top of each other: the aspirational description written for candidates, and the actual scoring criteria the hiring team will use. Your job is to recover the second one.

Read the posting twice. On the second pass, separate the requirements into what is genuinely non-negotiable and what is decoration. Anything phrased as "bonus", "plus", "nice to have" or "preferred" is decoration. What remains — typically five or so hard requirements and a few behavioural ones — is what you're being measured against.

Then ask the question the posting never states directly: what breaks if this seat stays empty? A role exists because something needs fixing. A posting that dwells on incident process and on-call rotation is hiring someone to stop the pages. One that dwells on migration and legacy systems is hiring someone to finish a move that has stalled. Writing to that underlying problem is what separates a tailored resume from a reformatted one.

Mirror the posting's exact vocabulary

Recruiter searches and parser filters match strings. Not synonyms, not concepts — strings. If the posting says "infrastructure as code" and your resume says "IaC", a literal search for the spelled-out phrase does not find you.

Go through the posting and list the exact terms it repeats, preserving their spelling and casing. Tools, certifications, methodologies, seniority language. Then check each one against your resume. Where the posting's term describes work you genuinely did, use the posting's term.

This is not keyword stuffing, and the distinction matters. Stuffing is attaching a term to work it doesn't describe. Mirroring is using the reader's vocabulary for work you actually performed.

Surface the skills you never wrote down

Most people's resumes understate them in a specific, predictable way: they describe the work and omit the words that classify it. Nobody writes "HTML" after a decade of front-end work. Nobody lists "issue tracking" after years of running sprints. It feels too obvious to state.

It isn't obvious to a text search. Go through your experience and name the category each thing belongs to. Selenium and Cypress are test automation. React is front-end development and JavaScript. Reviewing pull requests is code review and version control. A computer science degree carries data structures and algorithms.

The boundary to respect: this recovers vocabulary for things you did, and it never invents capability. There's a real difference between "I ran sprints, so issue tracking belongs on my resume" and "the posting wants Terraform, so I'll add Terraform." The first is accurate classification. The second gets found out in the interview.

Rewrite bullets as outcomes, not duties

A duty describes what you were responsible for. An outcome describes what changed because you were there. Hiring teams are trying to predict future impact, and only one of those helps them.

The most durable structure is the X-Y-Z form: accomplished X, as measured by Y, by doing Z. Lead with the accomplishment, quantify it where you honestly can, then explain the method. "Responsible for the deployment pipeline" becomes "Cut deploy time from 40 minutes to 6 by replacing the release script with a parallelised CI pipeline."

Where you have no metric, do not invent one. An unquantified true statement is always better than a quantified false one — the invented figure is exactly what collapses under a single follow-up question. Describe the qualitative outcome instead.

Prune what doesn't serve this application

Tailoring is subtraction as much as addition. Roles and bullet points that don't speak to the core problem dilute the ones that do, and on a one-page document that dilution is expensive.

Older or unrelated positions can compress to a single line — title, employer, dates — without disappearing entirely. That preserves your timeline, which matters because unexplained gaps invite questions, while reclaiming the space for evidence that counts.

Then judge honestly whether to apply

Before sending, count. How many of the non-negotiable requirements can you point to specific, defensible evidence for?

If it's most of them, apply — the tailoring work you just did will land. If it's around half, apply if you want the shot, but expect to argue for it and prepare those arguments properly. If you're missing most of them, the honest answer is that no amount of rewriting closes that gap, and the hours are better spent on a closer role.

This is the part most advice skips, because it isn't encouraging. But applying to roles you can't evidence is the most common way job seekers lose months, and recognising it early is worth more than another rewrite.

A repeatable checklist

Once you've done this a few times it takes about twenty minutes per application.

For each posting:

• List the non-negotiable requirements; discard anything marked bonus or preferred.
• Name the underlying problem the role exists to solve.
• Extract the exact repeated terms, preserving their spelling.
• Check each term against your resume; adopt the posting's wording where it describes real work.
• Add the category words your experience implies but never stated.
• Rewrite the top bullets as outcomes with honest metrics.
• Compress roles that don't serve this application.
• Count your evidence against the must-haves, and decide accordingly.