Tailor Your CV to a Job in 15 Minutes: The Master-Resume Method, With a Git Workflow for Developers

Written by Best JobFinder’s founder.

Before:

Worked on the payments backend and improved performance.

After, for a posting that asks for "high-throughput systems, Go, observability":

Cut p99 latency of the Go payments service from 840 ms to 210 ms by batching writes and adding per-route tracing; the service handles ~2,000 requests/s at peak.

Same job, same person. The second bullet exists because the writer went back to notes, found the numbers, and wrote them in the vocabulary of the posting. That is what tailoring is: not inventing, not rephrasing fluff, but choosing which true things to say first and saying them in the reader's words.

The problem is time. Done from scratch, tailoring takes thirty minutes and most people stop after the fifth application. The method below gets it to fifteen, repeatably, because almost all of the work happens once.

The master resume (do this once)

Create a document nobody will ever see. Three or four pages is fine. For every role you have held, write every bullet you can defend in an interview, with numbers wherever a number exists: latency, throughput, revenue, users, team size, time saved, incidents reduced. Tag each bullet, in a comment or a column, with the skills it proves: go, observability, postgres, mentoring, incident-response.

Add a block of alternative summaries, two or three sentences each, written for the two or three kinds of role you actually apply to: "backend engineer, distributed systems", "platform / SRE", "engineering lead".

This document is the asset. The tailored CV is a view over it.

The 15-minute cut

Time each step. The limits are the point; without them you will polish.

Minute 0 to 3: extract the requirements

Read the posting once. Write down five to eight hard requirements in the posting's own words. Not the whole wish list: the things that appear in the title, in the first paragraph, and in any sentence with "must" or "required". Mark each one as have, partly, or no.

If you have fewer than half, stop here and do not apply. Fifteen minutes is cheap; an application to a role you do not fit is not free, it costs you a slot in that recruiter's memory.

Minute 3 to 8: pick the bullets

For each have, find the master-resume bullet that proves it and pull it in. Prefer the ones with numbers. Reorder so that the bullets proving the title-level requirements sit first under your most recent role. Drop anything that proves nothing on your list. A role from eight years ago that is irrelevant to this posting becomes one line.

Resist adding anything. This step is subtraction and ordering.

Minute 8 to 13: rewrite the top of the page

Only three things get new words:

1. The summary. Start from the closest alternative summary, then edit it to name the role as the posting names it and the two or three requirements you most clearly meet.
2. The top three bullets of your current or most recent role. Rewrite them to use the posting's terms where those terms are true. "Build pipelines" becomes "CI/CD pipelines" if that is what they were. "Backend infrastructure" becomes "distributed systems" if it was.
3. The skills line. Reorder it so the posting's named tools come first, and remove the ones that are irrelevant to this role.

Everything else keeps the master wording. You are not rewriting a document; you are retitling its first screen.

Minute 13 to 15: verify

Read the posting's requirement list again, next to the CV. Each have should be findable by a recruiter searching that term. Then the two checks that catch the most damage:

• Nothing on the page claims a skill you could not talk about for ten minutes. If you used AI anywhere in this process, this is where it tends to have invented something.
• Paste the exported PDF into a plain-text editor. The text comes out in reading order and your contact details are present. (Why that matters is in the ATS post.)

Export, name the file Firstname-Lastname-CV.pdf (not resume_final_v3_COMPANY.pdf), submit.

Rules that keep this honest

• Mirroring is translation, not fiction. Use the posting's word for a thing you have done. Never add a thing you have not done because the posting wants it. The interview will find it, and it should.
• Numbers beat adjectives. "Significantly improved" is a tell that you do not know the number. If you genuinely do not, say what you measured instead: "reduced the on-call page count; 14 pages/week to 3".
• One page for the first several years, two after that, and nobody has ever been hired because of page three. The master resume holds the overflow.
• Keep the design version separate. If you like a two-column designed layout, keep it for emailing a human. The one that goes into an ATS is single-column text.

Resume as code, for the people who will enjoy it

If you are a developer, the master resume wants to live in a repository.

• Write it in Markdown or YAML. JSON Resume is a sane schema if you want structure, and there are renderers for it; a plain Markdown file plus Pandoc or a small HTML template and headless Chrome works just as well.
• main is the master. Each application is a branch named after the company: git checkout -b acme-platform-eng. The tailored cut is a diff against the master, which means you can see exactly what you reordered and reworded, and you can revert a change that did not work.
• Tag bullets with skills in front matter or trailing comments, and write a ten-line script that greps the master for the posting's terms and prints the bullets that match. That is minute 3 to 8 automated.
• Render to PDF in CI from a text layer (Pandoc, Typst, LaTeX, or HTML printed by headless Chrome). You get a clean parse for free and a build artifact per application.
• Keep a log.md: company, date, which branch, outcome. Six weeks in, that log tells you which rewrites got replies and which did not, which is the only feedback loop a job search has.

Why fifteen minutes and not five

You could do this in five by only changing the summary. The reason the bullet-selection step is worth the extra ten is the recruiter's search. They are typing the posting's terms into a box. Your summary is one line of hits; the bullets are ten. Reordering and rewording the bullets is where the document starts matching the query instead of merely gesturing at it.

And the reason it is not thirty is that you did the thinking once, in the master. Every application after the first is retrieval, not composition.

I build a job-search tool for a living. This method is what it automates, and it works just as well in a text editor; the tool only matters at the fortieth application.