How to write a cover letter from your resume and the job description

A cover letter is built from two documents you already have: your resume, which holds the facts, and the job description, which tells you which of them this reader wants. Pick the two requirements the posting cares most about, find the line on your resume that already proves each one, and write about those. Name the exact role, say why this company in one concrete sentence, and keep the whole thing under 400 words.

Pick the proofs from your resume

Start with the posting, not the letter. Read it once and mark the three or four things the team says it needs. Then open your CV and find the line that already proves each one.

A proof is an event, not a skill. "Experienced with Kubernetes" is a claim. "Moved fourteen services onto a managed Kubernetes cluster over one quarter and wrote the migration runbook" is a proof. A simple test: could a stranger read the sentence and ask two follow-up questions you can answer with specifics? If yes, it is a proof. If the follow-up is "what does that mean?", it is a label.

The middle column is the important one. If it is empty, the right column is empty too, however good the sentence would have sounded.

Two proofs, not five

A letter that names five accomplishments reads like a list, and a list of five is what the CV already is. Two proofs give you room to explain how and why, which is the only thing a letter can do that a resume cannot. The resume carries the inventory; the letter carries the argument.

A simple structure

There are four parts: heading, introduction, argument, closing. For a technical role, the argument is two paragraphs, and the heading is whatever your email client does for you. What follows is the shape, not a template to fill in. Purdue's OWL guide to cover letter content uses the same four parts and gives the one rule that matters here: one qualification per paragraph, proved with a specific example.

The opening: the exact role

Name the role as the posting names it. If it says "Senior Backend Engineer (Payments)", write that, not "backend position" and not "the advertised role". Use the company's name. One sentence on where you saw it is enough.

Then make the connection in the same paragraph. Not "I am confident I would be a great fit", but the fact that makes the reader keep going.

Dear Ms. Okafor,

I am applying for the Senior Backend Engineer (Payments) role at Nordwell, which I saw on your careers page. I have spent six years building payment APIs, most recently as primary on-call for card authorization.

Three sentences, and the reader already knows what you do and why this posting is not a random application.

Two body paragraphs, one proof each

Each paragraph: the situation in a clause, what you did, what changed. Then stop. Resist explaining the technology. The reader has read the posting and knows what Kafka is; what they cannot get from the posting is what you personally did when it broke.

Order matters. Put the proof that answers the posting's first requirement first. If the posting leads with reliability and you lead with a UI project, the reader has to do the work of connecting them, and readers do not do that work.

Why this company, without flattery

One concrete sentence. Not "your innovative culture" or "your dynamic team". Something you could only write about this company: a product decision you have used, an engineering post you read, a constraint of their market you recognize from your own. Purdue's OWL page on showing company knowledge makes the useful distinction: knowing the company is there to show how you match its needs, not to talk about the company instead of yourself. If you cannot find anything specific, cut the paragraph.

The close

One line: what you want next, and how to reach you. That is all. "I would welcome the chance to talk about the on-call rotation" tells the reader you have read the posting. "I look forward to hearing from you at your earliest convenience" tells them you have read other letters.

Words to cut

Filler adjectives are not banned because they are false. They are banned because they are unfalsifiable: "passionate", "results-oriented", "team player", "detail-oriented", "proven", "seasoned", "self-starter", "dynamic", "strategic thinker". Every one of them asks the reader to take your word for something, in a document whose whole job is to show evidence.

Hedging is the other leak. "Helped with", "was involved in", "contributed to", "participated in" all describe a distance between you and the work. If you did the work, say what you did. If you did part of it, say which part; a true "contributed to" beats a borrowed "led". The same rule that governs your resume governs the letter: no employment, tool, metric or title that is not yours.

Example letter (fictional, annotated)

The candidate, the companies and the numbers below are invented for this example. Marta is a backend engineer in Valencia with six years on payment systems, applying to a payments company in Amsterdam.

The posting asks for four years of backend experience, ownership of a production service including on-call, comfort with PostgreSQL and query performance, and — as a nice to have — Kafka and Terraform.

Here is one sentence from her first draft, and the same sentence rebuilt from what she actually has on file.

cover-letter-draft.docx

I am a passionate backend engineer who has worked on payment systems and is always looking for new challenges.

cv['senior backend engineer (payments), nordwell']

I have spent six years on payment APIs, including 14 months as primary on-call for a card authorization service, where a duplicate-charge incident led me to rewrite its retry logic.

Everything in that sentence is on file. The adjective is gone, the claim is now checkable, and the reader has a question to ask in the interview, which is the point.

The rest of her file, which the letter below also draws on: the authorization service was at a Spanish processor; the retry fix made the path idempotent and the postmortem changed the alerts on settlement mismatches; no repeat incident in the two peak seasons since, and the team still uses that postmortem as its template. The earlier job was at a smaller fintech; the queue consumer cut the worst-case confirmation delay from about an hour to under a minute and removed a single point of failure that had paged someone roughly monthly for a year. On Nordwell: its status page publishes settlement latency targets.

The finished letter, at about 250 words:

Dear Ms. Okafor,

I am applying for the Senior Backend Engineer (Payments) role at Nordwell, which I found on your careers page. I have spent six years building payment APIs, most recently at a Spanish processor where I was primary on-call for card authorization for fourteen months.

That service authorized about 1,200 requests a second at peak. When a retry bug produced duplicate charges over a weekend, I rewrote the retry path to be idempotent, added a reconciliation job, and wrote the postmortem that changed how we alerted on settlement mismatches. The fix held through the next two peak seasons without a repeat, and the postmortem is still the template the team uses for settlement incidents.

Before that, at a smaller fintech, I moved our order confirmation flow from a nightly cron job to a queue consumer. That cut the worst-case confirmation delay from about an hour to under a minute, and it removed a single point of failure that had woken someone up every month for a year.

Nordwell interests me because you publish your settlement latency targets and hold yourselves to them in public status updates. Most processors treat that number as internal. I would like to work somewhere it is a promise.

I would welcome the chance to talk about the on-call rotation and what the team is doing about reconciliation. You can reach me at the number above or at marta@example.com.

Sincerely,

Marta K.

What each paragraph is doing

The opening gives the exact role, the exact company, where she saw it, and the fact that establishes six years in payments. The first proof answers the on-call requirement with a service, a scale, an incident and a change that lasted — and it does not hide the incident, because a letter that only reports success is a letter nobody quite believes. The second proof is a different kind of work, architecture rather than incident response, so the two paragraphs show range without listing tools. The fourth paragraph is one checkable thing about Nordwell that could not be pasted into another application. The close names the next conversation and gives contact details; there is no thanks-for-your-time paragraph and no restatement.

The letter never mentions Kafka. The posting lists it as a nice to have and Marta has not used it, so the honest move is to leave it out and let the interview establish the gap.

Generating it in cv[0]

Writer's block is usually a symptom of not having decided which two proofs to use. Once you have them, the letter is forty minutes of work. cv[0] shortens the part before that: it reads the posting, checks which required and preferred terms your CV genuinely covers, and drafts the letter from the facts you approved for that application.

The drafting follows a fixed formula rather than a mood. The exact role title comes from the posting, the proof points must be traceable to your CV, the result runs 230–370 words, and filler adjectives such as "passionate", "results-oriented" and "team player" are blocked. Nothing is invented: no employer, tool, metric or title that is not already in your history and approved for that application.

The free plan includes one cover letter a month, alongside three tailored application packages and fifteen keyword checks; Pro raises that to 200 a month. Either way the letter arrives as a draft whose proof points trace back to your CV, and the review is still yours. Read it once for facts, once for anything you would not want to be asked about, and once aloud.

If you are still deciding what belongs in the letter, tailoring your resume to a job description produces the raw material; for a technical role, resume keywords for software engineers shows how to choose which terms are worth a sentence. When you are ready, start with your CV at cv[0]: it keeps your base history, the facts you approved, and every version you send in one place.