How to tailor a résumé per job without lying

A tailored résumé says the same true things in a different order, with the words the posting uses, and with the irrelevant true things cut. It does not contain anything that was not already true before you read the posting. That is the whole line, and it is much brighter than most advice admits — bright enough that we implemented it as code rather than as guidance.

Here are the four tests that line breaks into. We run them on every rewrite, including the ones our own rule engine produces with no model involved. You can run them on your own draft in about a minute a bullet.

Test 1 — every number lives in this bullet

Not in the résumé. In this bullet.

The failure is subtle and it is the most common one we reject. Your résumé says you cut build times by 40% at one job and that you managed a team of six at another. A rewrite that produces "Led a team of six to cut build times 40%" contains no number you did not write down, and it is still false: it has moved a quantity from one job to another and welded them together.

So the number check is scoped to the single bullet being rewritten. When a rewrite reaches for a figure, our guard says one of two things, and the difference is deliberate:

• "40%" appears elsewhere in the résumé but not in this bullet
• "40%" appears nowhere in the résumé

The first is drift. The second is invention. Both are rejected; only one is an honest mistake.

Spelled-out numbers count. "Forty percent" is the same claim as "40%", and so is "٤٠%" — a rewrite that cannot write digits will write words instead, and a check that only looks at digits catches nothing.

Test 2 — did the verb promote you?

There is a ladder in résumé verbs, and everyone knows it without being told:

• assisted, supported, helped, contributed, collaborated, participated — you were there and it was not yours.
• built, created, developed, implemented, shipped, wrote, migrated — you did the work.
• owned, led, drove, managed, architected, founded, ran — it was yours.

You may move down this ladder. You may never move up. "Contributed to the migration" becoming "Led the migration" is the single most common résumé lie, and it is the one an interviewer detects fastest, because the follow-up question is "who else was on it?" and the honest answer contradicts the bullet.

The same test catches direction. "Reduced latency" and "increased latency" are not two ways of saying one thing, and a rewriter optimising for strong verbs will occasionally flip one.

Read your rewrite's first verb against your original's first verb. If it claims more, put it back.

Test 3 — dates, degrees and licences are verbatim or absent

Years, month names, degrees, certifications, clearances. These have to appear in the source bullet, character for character, or they do not appear at all. There is no rounding, no "approximately", no inferring that a project running 2023–2024 makes a claim about 2025 safe.

This is the shortest test and it never has an edge case. Anything from this family that you did not already write is a fabrication, however small.

Test 4 — every tool named was already named here

This is the test that surprises people, and it is the one that does the most work.

Your résumé has a Skills section listing Terraform. The posting asks for Terraform. A rewriter looking at a bullet about an AWS migration will happily insert "using Terraform", because you do know Terraform and the project did use AWS.

Listing Terraform is not evidence that this project used Terraform.

So the check is: every noun in the rewrite must already be in the bullet it rewrites, in some inflection. Not the résumé at large, and — this matters — not the job description either. A posting that mentions Kubernetes does not license claiming Kubernetes. If the job description were an allowlist, the guard would be a machine for producing exactly the lie it exists to prevent.

The practical version, for a draft you wrote yourself: cover the posting, read the bullet, and ask whether you could name the release, the ticket, the week. If not, the tool does not go in that line.

So what is left to do?

Quite a lot, and it is the part that actually moves outcomes.

Reorder. Put the bullets that match the posting first. This is free, it is honest, and it is most of the effect — a recruiter reading in a hurry sees the top third of each role.

Cut. Six bullets under a job where two are relevant is worse than two. Everything you leave in competes for attention with everything else.

Use their words for your thing. If you wrote "data pipelines" and they wrote "ETL", and those are the same thing, write ETL. That is not a lie; it is a translation, and keyword filters match exact strings so it also happens to be the mechanically useful move.

Say the true thing more precisely. "Improved performance" is weaker than "cut p95 checkout latency from 900ms to 240ms" — and if you know the second, it was always available to you. Most weak bullets are not vague because the writer is hiding something. They are vague because writing precisely is harder.

Mirror the title when it fits. If the posting says Staff Data Engineer and that is genuinely your level, put those words in your summary. Not otherwise.

What to do with a "missing keywords" list

Every keyword scan, ours included, produces a list of terms in the posting that are not in your résumé. The list is useful and it is routinely misread.

It is not a to-do list. It is a diagnosis, and it has three possible readings per term:

1. You have it and did not write it. Fix the résumé. This is the common case and the whole point of the report.
2. You have it under another name. Write the long form. Our scan recognises "K8s" as Kubernetes and then tells you to spell it anyway, because the employer's filter will not be so generous.
3. You do not have it. Then it stays missing. A résumé with a Kubernetes line that cannot survive one question is worse than a résumé without one, because the second gets you a screening call and the first gets you a screening call that ends badly.

Crossing shows the third case as what it is. We do not offer a button that adds it.

What our rewriter does, and where it stops

The model never writes a résumé. It receives your bullets with ids attached and returns a patch — an ordering and a set of replacement sentences keyed to those ids. Employers, job titles, dates, degrees and school names are not in its output vocabulary at all, because there is no field in the response schema for them. Our code copies those across from your parsed résumé, untouched.

Then every returned sentence goes through the four tests above. A sentence that fails one is dropped and your original is used, with the reason recorded:

Kept your original wording — the rewrite changed more than we could verify.

A rejection degrades one bullet, never the request. And when no model is configured at all, the deterministic rule pass is the answer — it strips "Responsible for", "Helped with" and the adjectives with no referent, and it runs through the identical guard, because a rules engine can fabricate too.

None of this makes a rewritten bullet good. It makes it yours. The features page has the rest of what happens between your résumé and the employer's form.