How to tailor your resume to a job description (without rewriting it every time)

Most advice on tailoring a resume makes it sound like a rewrite for every application, which is why most people do it for the first five and then stop. It doesn't need to be. A tailored resume is usually the same experience, reordered and reworded so that whoever skims it for ten seconds finds the things the posting asked for without having to look.

Read the posting for what it actually screens on

A posting lists twelve requirements. Two or three of them decide who gets a call; the rest are aspirations or boilerplate. Before you touch your resume, find those few. The clues are fairly reliable:

• The title and the first line. "Backend Engineer — Payments" is telling you the domain matters as much as the language.
• What is listed first under requirements. Order is rarely random; the first two items are usually the ones the hiring manager wrote.
• Anything stated in years. "3+ years with Postgres" is a filter. "Familiarity with Kafka" is a nice-to-have.
• Words that repeat. If "stakeholders" appears four times, the job involves more talking to people than the title suggests.

Write those three things down. Everything that follows is about making them the easiest things to find on your page.

Change the order before you change the words

The top third of the first page does most of the work, because that is where a reader decides whether to keep reading. For each of the three things you wrote down, ask whether your best evidence for it is in that top third. If it is buried as the fourth bullet under a job from three years ago, move it — into your summary line, or up to the first bullet of the role where it happened.

For a payments backend role:
• Built the refund service handling ~40k transactions a day (Java, Postgres)
• Cut reconciliation failures by moving settlement to an event log
• Mentored two new joiners through their first on-call rotation

For a role that stresses mentoring and team process:
• Mentored two new joiners through their first on-call rotation
• Wrote the team's incident review template, now used across three teams
• Built the refund service handling ~40k transactions a day (Java, Postgres)

Nothing in that example is invented, and almost nothing is reworded. The difference is which fact a reader meets first.

Use their words — where they are also true

If the posting says PostgreSQL and your resume says Postgres, change it. If it says "stakeholder management" and you wrote "worked with the sales team", say both. This matters for people, who skim for the term they have in their head, and for software: most applicant tracking systems store your resume so recruiters can search and filter it, and a search for the posting's own wording will miss a synonym.

You will read claims that ATS software automatically rejects most resumes before a human sees them. It is more mundane than that. Systems vary a lot, but usually the software holds the applications and a person searches, sorts or filters them. Which is the practical point: write the terms they would search for, in plain text, wherever they are honestly true.

Keep a few base versions, not fifty one-offs

If you apply to two or three kinds of role — say backend and full-stack, or data analyst and business analyst — keep one base resume per kind, each already ordered for that kind of work. Tailoring for a single application then means adjusting the summary and the first bullet or two of your current role, which takes about ten minutes rather than an hour.

Name the files so you can tell later which one you sent where. When a reply comes back, you want to know which version earned it.

Formatting that survives being read by software

• One column. Two-column layouts are often read across both columns line by line, interleaving them.
• Standard section headings — Experience, Education, Skills — rather than clever ones.
• Real text, not text inside images or icons. If you can't select it, a parser can't read it.
• A PDF exported from a word processor, not a scan or a photo.
• Dates in one consistent format, on the same side for every role.

A ten-minute checklist per application

1. Write down the three things the posting screens on.
2. Pick the base version closest to the role.
3. Make sure each of the three has evidence in the top third of page one.
4. Swap your terms for theirs where both are accurate.
5. Read the summary line aloud. Would it make sense pasted into the posting?
6. Export, name the file after the company, and send.

The resume is half of it

A well-tailored resume submitted through a careers portal still waits in the same queue as everyone else's. The other half is getting it in front of a person — finding the recruiter's address and writing them a short email that makes the case in three sentences. The work you just did helps there too: the three things the posting screens on are exactly what that email should lead with.

Replyrate doesn't edit your resume. It uses it — to draft that email for a specific posting, after finding the person to send it to — and then asks a few days later whether you heard back, so you can see which version of your approach is working.