"Tailor your resume to the job" is advice almost everyone agrees with and few people can describe. It does not mean writing a new resume. It does not mean pasting the posting's keywords into a skills list. It means making it easy for one particular reader to see that your real experience fits their real need.
This guide walks through the five steps with a single example, so you can see each decision. You can do all of it with a text editor. Along the way there are screens showing how WingsOnCV does the same steps, for readers who want the time back.
The example we will carry through
Step 1: read the posting for must-haves and nice-to-haves
Postings mix three kinds of statement: what the job is, what you must already be able to do, and what would be a bonus. Read it twice and sort every requirement into one of two piles.
- Must-have signals: a "Requirements" heading, "in production", a number of years, anything repeated in both the job description and the requirements list.
- Nice-to-have signals: "nice to have", "a plus", "familiarity with", "exposure to".
- The job itself: the first paragraph usually tells you what you would work on in the first six months. Treat the nouns there as must-haves even if the list below omits them.
In the example, Kafka appears twice: once in what you will own and once in the requirements. That repetition is the posting telling you what matters most. Databricks appears in the first paragraph but not in the requirements, which makes it important context and a likely interview topic.
Step 2: map each requirement to your evidence
Now go through your resume with the must-have list beside it. For each requirement, find the specific line that proves it. Not a skill in a list: a bullet where you did the thing. Write the map down. This table is the most useful ten minutes of the whole process.
| The posting asks for | Alex's evidence | Verdict |
|---|---|---|
| 6+ years in data engineering | Two roles, 2017 to present | Covered |
| Kafka and Flink ingestion | Rebuilt order platform events on Kafka and Flink | Covered, but it is bullet two of the current role |
| dbt models in the warehouse | Re-modelled the largest fact tables in dbt | Covered |
| Airflow orchestration | Migrated 300 Airflow DAGs to GCP | Covered, in the older role |
| Spark in production | Cut nightly batch from 6 hours to 50 minutes with Spark tuning | Covered |
| Cutting cloud cost | Cut warehouse spend 40% | Covered, and it has a number |
| Mentoring other engineers | Led a team of five | Covered, worded as leading |
| Terraform | Listed in skills only | Thin: no bullet shows it |
| Databricks, lakehouse | Nothing | Missing |
| Snowflake, Great Expectations, logistics data | Nothing | Missing, nice-to-have |
Three things come out of a map like this. You see what to move up. You see where your evidence is thin, so you can strengthen it if a true line exists. And you see what is honestly missing, which you leave missing.
Step 3: re-order, don't rewrite history
Readers give the top third of page one most of their attention. Tailoring is mostly a matter of deciding what goes there. What you may move is wide. What you may not change is narrow, and it matters.
| You can move or change | You leave alone |
|---|---|
| The order of bullets inside a role | Employers, job titles and dates |
| The order of skills, and which ones you list first | The order of roles: most recent first |
| The summary: rewrite it for this job every time | Degrees, certifications and where you earned them |
| Which projects or achievements get a line at all | Numbers, unless you are correcting them |
For Alex, the Kafka and Flink bullet moves to the top of the current role. In the older role, the Airflow migration moves above the fraud feature store, because orchestration is in this posting and feature stores are not. The skills list now starts with Kafka, Flink, Spark, Airflow, dbt and Terraform, in the order the posting names them.
Step 4: use the posting's words, where they are true
Teams have their own vocabulary. If the posting says "data quality checks" and your resume says "validation framework", a tired reader may not connect them, and software that searches for a phrase certainly will not. Where you did the thing the posting describes, call it what the posting calls it.
Led a team of five; introduced data contracts and on-call.
Led and mentored a team of five engineers; introduced data contracts and data quality checks, and set up on-call.
The posting asks for "mentoring other engineers" and "data quality checks". Alex did both. The first version made the reader infer it; the second says it.
Data engineer with 9 years building batch and streaming platforms on AWS and GCP for retail and fintech.
Senior data engineer with 9 years building streaming and batch platforms on AWS and GCP. Production experience with Kafka, Flink, Spark, Airflow, dbt and Terraform. Cut warehouse cost by 40% and led a team of five from design to production.
The summary now answers the requirements list in its first two sentences, using only facts that appear lower on the page.
The line you do not cross
"Where they are true" is the whole rule. Alex has not used Databricks, so the word does not go on the resume, not in the skills list and not in the summary. Listing a tool you cannot discuss gets you an interview question you cannot answer. If you have related experience, state the related experience accurately and let the reader draw the comparison.
What to do about real gaps
- If you have it but never wrote it down, add a true bullet. Alex has written Terraform for every pipeline for four years, so "Provisioned pipeline infrastructure with Terraform" belongs in the current role.
- If you have something adjacent, say what it is. Experience with another warehouse is worth stating as itself.
- If you do not have it, leave it out and prepare an honest answer for the interview. A nice-to-have you lack is rarely what decides an application.
Step 5: cut what doesn't matter, then check
Every line that does not serve this application dilutes the ones that do. Cutting is not hiding: the experience stays on your source resume for the next job where it matters.
- Bullets about work the posting never mentions go to the bottom of their role, or go altogether if space is tight.
- Skills unrelated to the role come off the first line of the skills list.
Then check the result as if someone else wrote it.
- Every employer, title and date is unchanged from your source resume.
- Every tool named is one you could answer a detailed question about.
- Every number is one you can explain: what was measured, over what period, and what you did.
- Each must-have from the posting has a visible line of evidence in the top half of page one.
- The summary could not be pasted unchanged into an application for a different job.
- No page ends with a stranded heading, and no page holds only a few lines.
Doing the same steps in WingsOnCV
Everything above is manual work you can do tonight. It is also about an hour per job, which is why most applications go out untailored. WingsOnCV runs the same five steps on a copy of your resume, under the same rule as Step 4: it may use only what your resume already says. The judgement stays with you.
Your source resume is not touched. The tailored copy belongs to this one application, alongside its cover letter and interview questions, so tailoring the next job starts from the original again. More on this in Features, and on the rule itself in why our AI is not allowed to make things up.
Tailoring changes what the reader sees first. It never changes what happened.
Once the right lines are in the right place, the next improvement is in the lines themselves: resume bullets that carry weight.
Run the five steps on a real posting
Upload your resume, paste a job you are considering, and look at the covered and missing keywords before you change a word.
Create your account
