cv['tailoring']
How to tailor your resume to a job description (without lying)
cv[0]8 min read
In short
To tailor a resume to a job description, match the posting's requirements to work you actually did, then rewrite and reorder your existing evidence around those needs. Use the employer's terms where they fit. Keep titles, tools and results truthful, check keyword coverage, and save a separate version for that application.
Your CV can change emphasis without changing your history. Here is how, step by step, with a worked example.
The practical test for each edit is simple: what fact allows me to say this? Below, a fictional backend engineer works through a fictional posting. The candidate, job requirements and measurements are examples, not a real person's CV or a hiring study.
Read the posting like a parser
Keep the full job description beside your CV. Read for what the person will do, which qualifications the employer requires, and which ones are optional. Separate those from company background and benefits.
Start with eligibility conditions that wording cannot solve: location, work authorization, a required license, working hours. If something is unclear, record a question. Do not rewrite uncertainty into an assurance that you qualify.
Then mark the work itself. Look for tools and skills, but also verbs: maintain, investigate, design, mentor. They tell you what evidence to look for. Repeated responsibilities can guide emphasis; repetition alone does not make a preference mandatory.
Here is the posting for our example:
Senior Backend Engineer at a fictional developer-tools company. Required: Python, PostgreSQL, REST APIs and production incident response. Preferred: query performance tuning and mentoring engineers. Nice to have: Kubernetes.
Our fictional candidate, Maya Chen, has maintained a Python orders API, tuned PostgreSQL queries and taken part in an on-call rotation. She has not used Kubernetes or mentored engineers. That is already enough to make useful edits, while leaving those gaps visible.
Do not turn this exercise into a prediction about an applicant tracking system. You are identifying what the employer asked for. The guide to resume keywords and ATS explains the difference between finding terms and evaluating a candidate.
Build a keyword map (requirement → your evidence)
Before changing a sentence, make a table. Put the requirement on the left, a specific fact in the middle, and the editing decision on the right.
Oregon State University's tailoring worksheet recommends separating required and preferred qualifications and mapping the posting's language to your skills. Add an evidence column so the map also tells you what you can defend.
For Maya, it looks like this:
| Posting requirement | Evidence in her history | Editing decision |
|---|---|---|
| Python and REST APIs — required | Maintained a Python REST API for order management | Name the language and API in the relevant bullet |
| PostgreSQL — required | The orders API used PostgreSQL; she removed N+1 queries | Replace vague database wording with the actual database |
| Production incident response — required | Investigated failed order imports during an on-call rotation; wrote a recovery runbook | Describe the incident work and runbook |
| Query performance tuning — preferred | Grafana showed p99 latency falling from 800 ms to 120 ms after the query fix, over comparable production traffic windows | Lead with this measured result |
| Mentoring engineers — preferred | No supporting experience recorded | Leave out; ask whether there is relevant work she has forgotten |
| Kubernetes — nice to have | Never used it | Leave out |
Keep two different gaps separate. A wording gap means you have the experience but described it vaguely. A skill gap means you do not have the experience. Editing can fix the first. It cannot fix the second.
Your evidence does not have to be public. A private note about your contribution, the measurement method and the project context can help you check your wording. Keep confidential material out of the application. If a fact is uncertain, verify it before using it.
Rewrite, don't pad
Work on the strongest matches first. Within each role, move the most relevant bullet above routine duties. Keep the employment timeline clear; you do not need to rearrange your entire history to foreground one project.
A useful bullet names the action, the work or problem, and the result where known. CareerOneStop's work-experience guide recommends specific context and outcomes alongside the posting's relevant terms. That gives you more to work with than a string of keywords.
Turn a vague bullet into evidence
Maya's original line hides nearly everything the posting asks for. Her underlying facts support a much clearer version:
Worked on backend services and improved database performance.
cv['senior backend engineer']
Cut p99 latency on a Python REST orders API backed by PostgreSQL from 800 ms to 120 ms by removing N+1 queries.
The rewrite exposes the language, database, problem and outcome. It does not turn Maya into the architect of the whole platform. She should be able to explain what an N+1 query was in this API and how the latency was measured.
Numbers need their original context. Keep the metric, unit and scope together: p99 API latency is not average response time, and an API improvement is not a business-wide productivity improvement. Do not calculate a more impressive percentage just to decorate the sentence.
Write a strong bullet without a metric
Another line in Maya's CV can answer the incident-response requirement without inventing a reduction in downtime:
Helped the team with support and documentation.
cv['senior backend engineer']
Investigated failed order imports during production on-call and wrote a recovery runbook.
The artifact is the runbook. The scope is failed order imports. Both make the bullet concrete even though there is no measured outcome. If you cannot substantiate a number, describe the problem you handled, who used your work, or what you delivered.
Align the summary and skills
Once the bullets are accurate, write a short summary from the same facts. Maya could use:
Backend engineer working with Python REST APIs and PostgreSQL, with experience tuning queries and investigating production order-import failures.
She does not need to copy the advertised senior title into her employment history. A target role and a title you held are different facts.
In the skills section, put relevant tools you have used first. Keep enough context to distinguish work experience from a course or personal project. For more technical examples, see resume keywords for software engineers.
What you may not add
Write a short do-not-claim list before asking anyone, including an AI tool, to edit your CV. Include plausible claims that would be false for you. Maya's list would say:
- No Kubernetes experience.
- No mentoring or people-management experience.
- No ownership of the full backend architecture.
- No reduction in downtime or recovery time: neither was measured.
- No change to official job titles, employers or employment dates.
The list matters because exaggeration can sound like ordinary polishing. Changing “contributed to” into “led” changes your responsibility. Describing a course as production experience changes where you used the skill.
| Tempting edit | Why it fails | Defensible alternative |
|---|---|---|
| Add Kubernetes because the ad mentions it | The posting is not evidence of your experience | Leave it out; keep the genuine gap |
| Change “Software Engineer” to “Senior Backend Engineer” under an employer | It replaces the title you held with the one you want | Keep the title; show relevant scope in the bullets |
| Say the runbook reduced downtime | No downtime change was measured | Name the recovery runbook and the incidents it covered |
| Repeat every required term in a skills block | A list does not explain what you did | Place supported terms in the work they describe |
If the missing skill is central to the job, decide whether to ask about flexibility or spend your time on a closer fit. For a genuine move into a new field, the career change resume guide shows how to make transferable work visible without relabeling it.
One resume per job (keep a base CV)
Keep a base CV containing your full, true history: projects, tools, responsibilities, dates and outcomes. It can be longer than the document you send. (Which word goes at the top, and how long it runs, depends on the market: see resume vs CV.) Update it when you verify a new fact, rather than letting separate application files become conflicting records.
Create each application version from that base. Closely related jobs may need only a different summary, bullet order and selection of projects. If the evidence already fits, leave the wording alone.
Before exporting, compare the final version with the posting and the base:
- Evidence: can you explain your contribution behind every claim?
- Coverage: is each supported requirement easy to locate in the summary, skills or experience? Search for the actual terms, then read the surrounding sentence.
- Gaps: have unsupported tools or responsibilities slipped into the rewrite?
- Consistency: do titles, employers, dates, units and project scope still match the base?
- File: does the exported document contain the right version, with no placeholders or references to another application?
Open the PDF and copy its text into a plain-text editor to check the reading order and missing text. This is a useful inspection, not a simulation of an employer's system. The ATS-friendly resume checklist covers the formatting checks.
Save the posting and the exact version you sent together. You will have the same evidence available when preparing for an interview.
Doing it in cv[0]
The workflow starts with one base CV and a job description. The role screen checks how your history fits before you tailor. Rewrites reorder and re-aim your existing facts; numbers appear only if they are already in your history, and claims on your do-not-claim list are blocked after generation.
Use the keyword check to inspect required, preferred and nice-to-have terms. It needs a free account and includes 15 checks a month on the Free plan. Review each proposal against your facts; the audit trail keeps AI proposals and what you accepted. Coverage is a check on the document, not a promise about hiring.
If you prefer a chat-based process, use the ChatGPT resume prompt and review checks. The evidence map works with either approach.
Start with your CV, keep your full history as the base, and prepare one version you can explain for the next role. The same facts then feed the cover letter.