How to write a software engineer cover letter

The shape of an engineer’s cover letter

Four paragraphs, one job each. Past four, the reader skips to the last one and decides whether to go back. The subject line, the link in your header and the plain-text version you paste into a form are read as well, so they are taken apart here too.

1. 1
   The subject line: the posting’s title and your name

   Copy the role title from the posting exactly, add your name, and carry the requisition number if there is one. Engineering teams often run several near-identical openings at once — backend, platform, data — and a vague subject line files the letter under the wrong one, where nobody opens it again.

2. 2
   Paragraph one: the posting × you

   Sentence one quotes what the posting asks for; sentence two gives the matching result with a figure; sentence three says this is their problem. No introduction, no enthusiasm.

3. 3
   Paragraph two: two technical results

   Pick the two resume lines closest to their system and give each a figure. Name something they published — a blog post, API docs — to prove you read it.

4. 4
   Paragraph three: a working habit

   One concrete habit (instrument before optimising, delete alerts that never fire before incidents), not an adjective. Leave one real question so the reader has a reason to reply.

5. 5
   Paragraph four: when and how

   Start date, how to talk, resume attached. Two sentences. Do not thank them a third time.

6. 6
   The header: one link, a city, a time zone

   Name, email, city and time zone, plus one link that will actually be opened — GitHub or a portfolio, one of them, not three. No photograph, no street address, no date of birth. Whatever that link shows first is the reader’s first impression of your code, and it happens before they reach paragraph three.

7. 7
   The plain-text version, for the box in the form

   Half of engineering applications give you a text area and no attachment. Write a version with no bold, no bullets, no markdown backticks, and a blank line between paragraphs. Do not paste code into it; nobody reads code in a form field. Link to it instead and say which part to look at.

What each paragraph of this letter is doing

Paragraph by paragraph: which sentence carries which job, and what was deliberately left out.

1. 1

   Your posting for a Senior Backend Engineer asks for someone who has run payment traffic at scale and kept it correct under load. For the past [N] years at a Series B logistics SaaS I have owned the order-routing path that handles [N] million requests a day, and the idempotency layer I designed for payment webhooks removed the [N] duplicate charges a month that support had been refunding by hand. That is the problem your team describes, and it is one I have already solved once.

   The first sentence restates the posting’s requirement (scale, correctness); the second gives two resume results with [N]; the third joins them. No “I am excited”, no “your esteemed company”.

2. 2

   Two results from that work bear directly on your stack. I cut p95 latency on the routing API from [N] ms to [N] ms by replacing synchronous fan-out with a queue-backed worker pool, which is the same shape as the settlement pipeline your engineering blog describes. I also migrated [N] services from a single Postgres instance to sharded clusters across [N] cutovers with zero recorded downtime; the runbooks from that migration are still the ones the team uses.

   Two results, one figure each, both shaped like the reader’s own system (a settlement pipeline, a database split). “Your engineering blog” is the evidence of homework — worth more than any adjective.

3. 3

   I would bring the habit that made those numbers possible: I instrument before I optimise, and I delete alerts that never precede an incident, which halved on-call pages in my current role. I read your API documentation before applying. The versioning approach in it is one I would be glad to build on, and I have [N] questions about it that I would rather ask in a conversation than guess at here.

   The habit is written as actions, not traits: instrument before optimising, delete alerts that never preceded an incident. It ends on a genuine question, which is the most common reason a hiring manager replies.

4. 4

   I can start in [N] weeks and am available for a technical conversation at any time that suits your team. My resume is attached, with the figure each claim rests on.

   Only two things: when, and how. “My resume is attached, with the figure each claim rests on” sends the reader back to the resume and restates that the letter invents nothing.

Seven ways to write the first sentence

The first sentence decides whether the second is read. None of these begins with “I am writing”.

• Your posting asks for someone who has kept a payments system correct at [N] million requests a day; for the past [N] years that has been my job.

  Requirement → your job, in one sentence. For postings that are specific about the problem.

• The settlement pipeline described on your engineering blog has the same shape as the routing path I rebuilt last year, so I will be direct about what I did to it.

  Opens from something they published. For companies with an engineering blog.

• I have migrated [N] services off a single Postgres instance with zero recorded downtime, which is the migration your team is hiring for.

  One result → the reason the role exists. For postings built around a single technical problem.

• [Name] on your platform team suggested I write to you directly about the on-call load this role is meant to reduce, so I will start with what I did to ours.

  The referral opening: the name, then straight to the problem the headcount exists to fix. Written so the paragraph can be pasted into an internal referral form as it stands.

• I spent [N] years as the person paged when the ingestion pipeline broke, which is how I ended up writing the service that replaced it.

  Opens from how you came to the work. For a path that is not a straight line: one sentence carries both the reason and the thing you shipped, with no confession attached.

• We have been running your open-source client in production for [N] months, and the two issues I filed against it are what sent me to your careers page.

  The strongest opening when you are already a user of their technology. Not praise — a record of use they can go and check.

• Your posting does not say which part of the platform this team owns, so here are the two systems I have run, and you can place me.

  For a vague posting. It does not pretend to know, hands the judgement back, and still puts two concrete systems on the table first.

Who opens this letter, and what they are checking

An engineering application passes through four or five pairs of hands before an interview is booked. Each of them spends under a minute on the letter, and each is looking for something different. Knowing which is which is how you decide what cannot be cut.

1. 1
   The technical recruiter, first pass

   They are confirming whether you can be moved forward at all: work authorisation, time zone, the level the role is open at, and whether your stack overlaps theirs. If those answers exist only on the second page of your resume, they send an email and the week is gone. That is what the last paragraph of the letter is for.

2. 2
   The hiring manager, who reads it word by word

   They are testing the one thing the interview loop cannot: whether you can describe a technical decision in ordinary sentences. Not whether you can code — there are [N] rounds for that. Whether you can write “at peak our p95 was hostage to the slowest downstream call, so we replaced the synchronous fan-out with a queue”. Someone who writes in stacked nouns usually talks that way in the design round too.

3. 3
   A senior engineer on the team, doing resume rotation

   Bigger teams hand screening around the engineers. What that reader is reading for is scope: did you design the system, or file tickets against it? “The order-routing path I own” and “the order-routing project I was part of” are a level apart to them. Pick the verb you are willing to be questioned on.

4. 4
   Whoever refers you

   A referral letter is often pasted straight into an internal referral form, or forwarded with two lines above it. So write the first paragraph to be forwarded as it stands: not how interested you are in the company, but what you have built and where it meets this opening. The less work you leave them, the more likely they press submit.

5. 5
   The interview panel, later

   Plenty of teams attach the letter to the interview packet. The two results you name become the opening question in the behavioural round and the frame of the design round. The test for each is simple: can you hold forty minutes on it, including the trade-off you got wrong at the time? A result you cannot defend is a question you set for yourself.

6. 6
   Whoever clicks the link

   Engineering has a step other fields do not: the reader opens the GitHub or portfolio link in your header, usually before they reach paragraph three. Thirty seconds — do the top repositories have a README, when was the last commit, does the code read like the sentences in the letter? Click your own link before you send it.

When it stops being the same letter

One resume can go to ten companies. This letter cannot. There are six or seven points where an engineering letter has to be rewritten — not the company name in it, the argument it makes.

• Early-stage or established: breadth against blast radius

  A young team has no platform group, so they want evidence you shipped without one: you wired the CI, you wrote the migration, you carried the pager. A large engineering organisation wants the opposite proof — that you changed a system people depend on and did not break it: staged rollouts, a rollback you actually used, three dependent teams you kept in step. The same history, two letters, and usually two different results in paragraph two.

• Product engineering or platform and infrastructure

  A product team wants the user-visible outcome and the scope you cut to ship on time. A platform team has no users except other engineers, so what counts is adoption and deprecation: how many teams picked up what you built, and how you got the old thing switched off. “I built an internal framework” and “I moved [N] teams off the old framework” are different claims, and only the second answers a platform posting.

• A referral or a cold application

  A referral letter is written to be forwarded: the name in the first line, the thing you worked on together in the second, the paragraph kept pasteable into a referral form. A cold application has none of that, and there is only one substitute — proof you read what they published: the versioning policy in their API docs, the incident they wrote up, an issue you filed against a repository they maintain.

• Applying across borders: authorisation, notice, overlap

  Applying from one country to a role in another, three administrative facts decide whether the recruiter can move you forward at all. A paragraph on them is a waste; hiding them costs a round of email. One sentence in the close: your current work authorisation, your notice period, and how many hours a day you can overlap with their core hours. It does not lose you points. It moves the question out of the inbox and into the letter.

• Moving in from an adjacent role

  From QA, data analysis, firmware, support engineering or a self-taught route, the barrier is never enthusiasm. It is whether anyone else runs code you wrote. Point at one concrete thing: the internal tool your team opens every day, the pipeline you took over and kept alive, the pull requests that were merged. Courses and practice problems belong to the education section, not to the letter.

• Agency and systems integration against in-house product

  A consulting background tends to produce a letter that lists six client projects. Replace the list with one: a system still running in production, what it does, which part was yours, and how long you maintained it after launch. An in-house team is working out whether you look after what you write, not how many deliveries you have signed off.

• Senior and staff are not the same letter

  A senior letter argues depth: one system, two figures, one design trade-off you made and can defend. A staff letter has to argue that your effect survives past your own keyboard — the design document other teams adopted, the migration other people executed, the interface two groups finally agreed to share. Send a senior letter for a staff opening and the loop gets scheduled a level down.

The mistakes engineers make most

• Retelling the resume

  The letter is not the resume in prose. Pick two lines, explain their relationship to the reader’s system, and leave the rest on the resume.

• Stacking technology names

  Listing Kubernetes, Kafka and gRPC is not an argument. The reader wants what you solved with them and by how much.

• Praising the company

  They know they are an industry leader. One sentence proving you read their docs or blog is ten times stronger.

• No figures, or invented ones

  A result without a figure reads as average; an invented figure gets found in the interview. Leave [N] and go look it up.

• Thanking three times

  Once. Every extra thank-you moves the letter’s weight from what you did to how polite you are.

• Spending your interview material

  A paragraph that explains the whole design leaves the reader nothing to ask you about. Give the result and one figure; keep how you did it. The letter is not there to prove you were right, it is there to make someone want to ask.

• A side project standing in for work

  Side projects belong in the letter, but say who runs it: where it is deployed, whether a second person uses it, when it was last committed to. A project with no users reads as coursework, and putting one in paragraph two pulls down the credibility of everything beside it.

• A technology used once, written as a specialism

  “Production experience with Kafka” that turns out to be one tutorial surfaces in the first ten minutes of the phone screen, and from that moment every other sentence in the letter is read again with suspicion. Name only the technologies you would be glad to be asked how you partitioned.

• Not one system of theirs anywhere in the letter

  What gives away a letter sent to ten companies is not its tone. It is that it talks only about you from beginning to end. One sentence about something they published — documentation, a blog post, a repository, a postmortem — makes it impossible for the letter to be a broadcast. Without that sentence, sincerity does not save it.

• Implementation with no outcome, or outcome with no implementation

  A paragraph about which patterns you applied and which library you swapped, with nothing about what the system does now, reads as engineering notes. A paragraph about improving the user experience with nothing about what you changed reads as though someone else’s product manager wrote it. Both halves go in the same sentence: what you changed, and what it became.

FAQ

Does anyone read cover letters for engineering roles at multinationals?

First-round screening at large companies often does not. The hiring manager does — when a referral lands, or when a candidate reaches a second round — and reads closely. Write for that person, not for the ATS.

So the letter is short, carries figures, and matches their system.

Should the letter link to GitHub?

In the header contact line, not the body. A sentence like “the runbooks from that migration are still the ones the team uses” says more about your engineering than a link does.

I am early-career or changing fields and do not have two big results. What then?

One result plus one side project works, provided the project has something verifiable: open source, deployed, used by someone. Figures still stay [N]; do not cover the gap with “significantly improved”.

How long should it be?

Three to four paragraphs, 200 to 300 words. The sample on this page is [N] words; the letter check beside it shows the actual count. Past 320, the engine says so.

I need visa sponsorship. Does that go in the letter?

Yes, in one sentence, in the last paragraph. Screening is checking for it anyway, so leaving it out buys you either an email or a wrong assumption. State it as a fact rather than an apology: “I would need visa sponsorship for this role and can start [N] weeks after an offer.”

What does not belong is a paragraph of immigration history. That is an HR form and a conversation, not a cover letter.

The role is remote. Should I mention my time zone?

Mention the overlap, not the location. “I can overlap [N] hours a day with your core hours” answers what the reader is actually calculating; “I am based in [City]” hands them the calculation.

If you are willing to shift your day for their meetings, say so in the same sentence. It is the condition remote teams stall on most often.

The form has only a plain-text box. What happens to the formatting?

Write the plain-text version first: no bold, no bullets, no markdown, a blank line between paragraphs. Many forms strip formatting, and people find this out after the letter has gone in as one solid block.

The length does not change — still three or four paragraphs. Save a PDF of the same text once the plain version is final, so both say the same thing.

I do not have a computer science degree. Should I explain that?

Do not explain it; replace it. One sentence pointing at code other people run — a service in production, merged pull requests, an internal tool a team depends on — does more than any account of how you learned.

If a degree is a stated requirement, that is a screening rule and the letter cannot move it. Spend the hour on a posting that does not have it.

More Tech cover letter examples

• Data Scientist

Related guides

• STAR: how to answer with evidence
• The interview loop: what each round tests
• Preparing for an all-English interview