Does a backend engineer's cover letter get read?

You have sent a lot of applications and heard very little back, and somewhere in that pile is a question you keep re-litigating: is the covering letter doing anything at all?

Honest answer: for a large share of backend roles, no. Not much. The CV, the referral and the system design round decide it. But there is a narrow set of situations where the letter is the only thing that can save an application, and if you are getting silence, there is a reasonable chance you are in one of them and writing the wrong letter.

This is about working out which situation you are in.

What the letter is competing with

A backend hiring manager filling a req has a pile of CVs, a referral or two, and a pipeline that ends in a technical interview that will tell them far more than any prose. For a mid-level role with a well-defined stack, the screen is mostly mechanical: does this person have production experience in something close to what we run, at something close to our scale, in something close to our domain.

That is why your letter often does nothing. Not because nobody reads prose, but because the decision at that stage does not need prose. If the advert says Go, Postgres, Kubernetes, event-driven, and your CV says five years of Go and Postgres on a team that ran its own Kafka cluster, the letter is redundant. You are through on the CV. If your CV says four years of PHP and a Laravel monolith on a single RDS instance, a very good letter is unlikely to change the arithmetic of a screen with ninety other applicants in it.

The letter earns its keep in the middle band — where a human looks at your CV, hesitates, and needs a reason to keep reading.

I don't know of any reliable public data on how often covering letters are read for engineering roles specifically, and anyone quoting you a percentage is making it up. What you can observe directly is the application form. If the cover letter field is marked optional, that is a signal about how much the process expects from it. If the form instead asks you a specific written question — "describe a system you designed that you would build differently now" — that is a signal in the other direction, and it should be answered like an interview question, not like a letter.

Where it actually gets read

Five situations, in rough order of how much difference the letter makes.

The company has fewer than about fifty engineers and the hiring manager reads applications themselves. At a seed or Series A company, the person deciding is often the person who will be doing code review on your PRs. They are not screening against a req; they are trying to imagine you in the team. They will read two paragraphs. They will also notice if you clearly have not looked at what they build.

You are an unusual fit. Java to Go. Backend to backend, but from ad tech to healthcare, or from a data-intensive batch world to a low-latency request/response one. From a 400-engineer company to a 12-person one, or the reverse. Nobody reads a CV and spontaneously concludes that your experience transfers. You have to say so, and say why, in a way that shows you understand what is actually different about their problem.

There is a discontinuity someone will have to explain away. A two-year gap. Three jobs in three years. A layoff. A title that says "Full Stack" when the work was ninety per cent backend. Left with no overlapping role. Someone in the process will raise it. The letter decides whether they raise it as a question or as a reason to pass.

Regulated or public-sector hiring where the written application is scored. UK Civil Service roles recruited under Success Profiles ask for evidence against named behaviours and a personal statement, and those are assessed against a published framework rather than skimmed. The same structured-form pattern turns up in NHS Digital-adjacent roles and some FCA-authorised firms. Here the written submission is not a courtesy — it is the sift. Write it against the framework, using their vocabulary, with one example per behaviour.

Staff and principal roles. Above senior, a large fraction of the job is written: design docs, RFCs, ADRs, the memo that gets four teams to agree on an event schema before anyone writes code. A hiring manager for a staff backend role is reading your letter partly as a writing sample. If it is three paragraphs of generic enthusiasm, that is information about how you would write an RFC.

Where it is ignored

Large-company pipelines with a recruiter screening against a structured req. The recruiter's job is to match your CV against a checklist and pass you to a phone screen. The letter is usually not part of that workflow, and writing a longer one will not change it.

Referral-driven processes. If someone inside vouched for you, you are already past the stage the letter addresses.

Agency-submitted applications. The recruiter frequently reformats your CV onto their own template before the client sees it. Your letter may not survive that step at all.

And any process where the first real gate is a take-home or an online assessment. If the advert says "apply and you'll receive a coding exercise", the letter is an administrative field.

The two things a backend hiring manager wants the letter to answer

One: do you understand what this system actually does, and do you want to work on that specific problem?

Not "why do you want to work at Monzo". Why this system. Backend roles are defined by their constraints, and the constraints differ enormously between adverts that use identical words. "Distributed systems" at a payments company means idempotency keys, exactly-once semantics that are really at-least-once with dedup, ledger correctness, and reconciliation. At an ad exchange it means a p99 budget measured in single-digit milliseconds and a willingness to drop requests. At a logistics company it means long-running workflows, compensating transactions and a lot of state that lives for weeks.

If you can write two sentences showing you know which of those you are applying to, you are already ahead of most of the pile. Backend teams leave evidence lying around: engineering blogs, open-source repos, conference talks, public API docs, incident write-ups. Read one. Reference the actual thing. "Your post on moving the settlement path off the monolith while double-writing for six weeks — that cutover problem is the part of the job I'd want" is worth more than any amount of stated enthusiasm, because it cannot be produced by someone who did not do the work.

Two: what is the reason to reject you, and what is your answer to it?

Every application has one. Find yours and address it in a sentence or two, without apology.

The stack mismatch: "The advert says Kotlin and Spring Boot. My JVM work has been Java with Dropwizard and Micronaut — same concurrency model, same JVM tuning problems, and I've shipped Kotlin in side services. I'd expect to be slow on idiomatic Kotlin for a month."

The scale question: "I haven't run anything at your request volume. What I have done is take a Postgres instance from a single writer to logical replication plus read replicas when our read path started falling over, which taught me more about query planning than about scale."

The production-ownership question, which is the one hiring managers most often cannot answer from a CV: have you carried a pager. Have you been the person who woke up at 3am to a Kafka consumer lag alert and had to decide whether to replay or drop. Teams that run their own on-call rotation care about this a lot more than the advert suggests, and almost no CV states it. One clause: "I've been in a six-person on-call rotation for the past three years, including the payments path."

That is the whole job of the letter. Show you understand the specific system. Pre-empt the objection. Everything else is filler.

What to cut

The opening paragraph announcing that you are writing to apply for the Senior Backend Engineer position. The reader knows.

The list of technologies already on your CV. If the letter restates the CV, it has cost the reader time and given them nothing.

Adjectives about yourself. "Passionate", "highly motivated", "strong problem-solver" — these are unfalsifiable and everybody writes them, which is exactly why they carry no information.

The company-history paragraph. Telling a fintech what year it was founded does not demonstrate research. Referencing their approach to idempotent retries does.

Anything over one page. For most backend roles, three to five short paragraphs is the honest length, and the structured-application exceptions above are structured precisely because they want something different.

What is repeated and not supported

That a cover letter must be addressed to a named individual or it will be discarded. Addressing it to a person is fine and mildly better than "Dear Sir/Madam". There is no good evidence that the absence of a name gets you rejected, and hiring managers at companies that do not publish their org chart know perfectly well that you could not find the name.

That you should keyword-match the letter to get past automated filtering. The screening that matters for backend roles is usually a recruiter or hiring manager reading a CV, and applicant tracking systems are mostly storage and workflow tools rather than automated rejection engines. Stuffing Kubernetes into a sentence where it does not belong costs you with the human and probably buys you nothing with the machine. Do make sure the genuinely required technologies appear on your CV in plain words, because a recruiter may well be searching for them — that is a CV problem, not a letter problem.

That you should always attach one. If the field is optional and you have nothing specific to say about that system, a generic letter is slightly worse than no letter, because it demonstrates you applied without reading.

What to do next

Go back through your last twenty applications and sort them into two piles: ones where a human hiring manager plausibly read the application, and ones that went into a large-company or agency pipeline. If the silence is concentrated in the second pile, the letter is not your problem and rewriting it is procrastination — look at the CV, the stack match, and whether you have any route to a referral.

If the silence is in the first pile, pick the five roles you most want, and for each one write down two things before you write any prose: the specific thing their backend does that is technically interesting, taken from something they published, and the single clearest reason someone would pass on you. If you cannot fill in the first box after fifteen minutes of looking, that is useful information about whether to apply at all.

Then write four paragraphs. Their system. Why that problem. Your objection and your answer to it. One line on availability. Stop.

If the bottleneck is that doing this properly takes an hour per advert and you have forty to get through, jobmarket.pro reads each advert in full and drafts the application from one profile of your actual experience, without inventing any of it.