Paragraph by paragraph
I'm applying for the Senior Software Engineer role on the BBC World Service web team. Before writing, I spent an evening in the Simorgh repository to see how one React application serves news in 41 languages. Your advert also describes work I have done at Monzo for the last four years, mainly performance and a gradual move to TypeScript.
Their product first, then his experience
He starts with something specific to them, their public codebase and its 41 languages, before saying anything about himself. Then he picks out two things from the advert he has already done. In two sentences the manager knows why he applied and why he might fit.
At Monzo I led the TypeScript migration of a codebase of 80,000 lines. We moved it one service at a time behind a strict compiler setting, with no feature freeze, and the type checker caught more than 300 errors that had been reaching production. I also built the React component library that three product teams now share, which cut the time to build a new screen by about 40%.
The migration story
Lots of engineers have "led a TypeScript migration" on their CV. What makes this one believable is how he did it (service by service, with a strict compiler setting and no feature freeze) and the result a tool measured. The component library result is about other teams, which is what a senior engineer is hired for.
On scale, the Node services I designed at Monzo handle more than two million transactions a day at 99.9% availability. At Deliveroo I built the WebSocket order tracking used across 12 markets, and code splitting and lazy loading took 35% off our page load time, which matters most to readers on older phones and slow networks.
Traffic and performance numbers
Transactions per day and availability are the two numbers engineers ask about first, so he gives both. He also connects the Deliveroo page speed result to the BBC's readers on older phones and slow networks, which gives it a reason to be in this particular letter.
I've mentored four engineers at Monzo through weekly reviews and pairing, and I write things down: design documents, migration guides and the occasional postmortem. I can share the migration plan, with internal details removed, if it would help you see how I work.
Mentoring and writing things down
A senior engineer is expected to help other people and to document decisions, so that gets its own paragraph. Offering to share the migration plan invites them to check his work, and mentioning that internal details would be removed shows he takes confidentiality seriously.
I live in London and can be in the office as often as the team is. My notice period is one month, and my CV and GitHub profile are linked above. Thank you for reading.
The practical details
For a London role a manager wants to know where you live, how often you can come in and your notice period. He answers all three in one sentence. The links are already in the header, so he doesn't repeat them.
What to link, and in what order
An engineering manager will click at most two links from a cover letter, so pick the ones that back up your letter best. Rank your evidence like this and link the top two you can.
| Evidence | What it proves | How to point at it |
|---|---|---|
| A merged contribution to their own open source code | You can work in their codebase, with their review process. | Link the pull request itself, not your profile. |
| A design document or migration plan | How you think before you build, at senior scope. | Offer it with internal details removed, or link a public version. |
| A postmortem you wrote | How you behave when things break. | Only if it is public or you have permission; otherwise describe it in one sentence. |
| A talk or a technical blog post | That you can explain your work to other engineers. | Link the recording or the post, with its date. |
| A side project with real users | Ownership from idea to production. | Link the live product and the repository, and say how many people use it. |
Nobody minds an old GitHub profile you no longer use, but linking to it draws attention to it. Leave out any link that does not support the letter's argument.
The short version, for an application form or a message
Many applicant tracking systems give you an optional text box instead of an upload, and a short note to the hiring manager on a professional network works best under 120 words. Keep the codebase line and one result.
Saying scale so engineers believe it
Engineers tend to check scale numbers in their heads as they read. Two habits help yours stand up.
Know what your availability figure means in minutes. An interviewer may ask, and the arithmetic is simple: the share of time a service may be down, multiplied by the time in the period.
| Availability | Downtime in a month of 30 days | Downtime in a year |
|---|---|---|
| 99% | About 7 hours 12 minutes | About 3.7 days |
| 99.9% | About 43 minutes | About 8.8 hours |
| 99.99% | About 4 minutes 19 seconds | About 53 minutes |
Turn daily totals into rates, and know your peak. Two million transactions a day averages about 23 a second across 24 hours. Real traffic is never flat, so if you know the peak, give it; if you only know the daily total, give that and nothing invented.
Finally, say what you owned. "Designed", "built", "maintained" and "was on call for" describe four different jobs, and a hiring manager will ask which one you mean.
Other engineering situations, other first lines
Graduate or bootcamp
You have little paid work, so lead with the most real thing you built: who used it, what broke and what you changed. Course names come last.
The expense tracker I built in my final year now has 300 weekly users at my university, and keeping it running taught me more about databases than any module did.
Agency or consultancy to product company
Product teams worry that agency engineers build something, hand it over and move on. Show something you maintained over time and a decision you made for the long term.
After four years building client platforms at an agency, I want to own one product for longer than a contract, and your payments team is where I would like to do it.
You need visa sponsorship
Say it once, plainly, near the end, with your current status and dates. If you leave it out, it will come up later anyway, usually at a worse moment.
I hold a Graduate visa valid until August 2027 and would need Skilled Worker sponsorship from then, which I mention now so it does not surprise anyone later.
After a layoff
One neutral sentence is enough. Spend the rest of the letter on what you shipped before it.
My role ended in September when my employer closed its London office, and I am looking for a backend team where I can keep building payment systems.
Changing language or stack
Be honest about the language you haven’t used much, and point to what carries over: the kind of systems, the scale, the way you work.
Most of my work has been in Node and TypeScript, and over the last six months I have been writing Go for an open source queue library, because your platform team runs on it.
What an NDA keeps out of your letter
Most engineering contracts restrict what you can say about your employer's systems, and a careless cover letter is a common way to break that. Keep these out:
- Internal names of services, tools and projects. Describe them by what they do: "the payments ledger service", not its codename.
- Figures that are not public. Use the numbers your employer has published, or round your own and describe them, such as "more than two million a day".
- Incident details beyond what was announced publicly: what failed, for which customers, and why.
- Unreleased products and anything on a roadmap.
- Code you wrote for an employer, unless it is already open source.
Offering material "with internal details removed", as James does, signals that you know where the line is, which is itself something a hiring manager is looking for.
Junior, mid, senior, staff: what the letter must show
You can use the same structure at any level. What changes is how big the evidence needs to be, so match yours to the level in the advert.
| Level | Lead with | Show also |
|---|---|---|
| Graduate or junior | Something you built and shipped, with its users. | How you learn: a bug you tracked down, a review comment that changed how you work. |
| Mid level | A feature you owned from design to production. | A measurable result and how you worked with product and design. |
| Senior | A technical change across a codebase or a team, like a migration. | Mentoring, writing, and judgement under real load. |
| Staff or principal | A decision that changed how several teams build. | What you weighed up, and what you said no to. |
Five ways engineering letters lose the reader
Listing technologies instead of work
A paragraph of technologies repeats the skills section of your CV and says nothing about what you did with them.
Name a technology only inside a sentence about something you built with it.
Claims nobody can check
Lines like "passionate about clean code and best practices" appear in so many letters that readers skip them.
Show the practice: a migration done without a feature freeze, a review habit, a document you wrote.
Big numbers without your part in them
"Worked on a system handling millions of requests" hides whether you designed it, built one part of it or watched its dashboards.
Use the verb that matches your role: designed, built, maintained or was on call for.
Sharing internal details
Codenames, private metrics and incident details can break your contract, and a careful reader will wonder what you would share about them.
Describe systems by what they do and use public or rounded figures.
Nothing about what they build
If the letter never mentions what the company makes, it could have been sent anywhere, and the reader will assume it was.
Read their engineering blog, documentation or open source code and connect one thing in it to your experience.
Length and format for tech applications
- Length: under 350 words as an upload, under 120 in a form's text box or a message.
- Greeting: first names are normal in most tech companies; the International format's Kind regards works in both the UK and abroad. If you cannot find the hiring manager's name, write to the team: Dear World Service web team.
- Links: written in full in the header (github.com/jamesthornton), because some systems strip hyperlinks from uploaded files.
- Text box or PDF: if the form offers both, upload the PDF and paste the short version, so a reader on either screen gets the point.
- Spelling: British English for UK employers, American for US ones; your code can stay as it is.
The main points from this page
- 1Open with something specific to their product or code, then the overlap with your work.
- 2Tell one technical story with its method and a result a tool measured.
- 3Know your availability figure in minutes and your traffic as a rate.
- 4Use the verb that matches your role: designed, built, maintained.
- 5Keep codenames, private metrics and incidents out; offer redacted evidence instead.
Frequently asked questions
Do software engineers need a cover letter?
Often it is optional, and many engineers skip it. That is exactly why a short, specific one helps: it is the only place to show you read their product or code and to give one result in context. If the form has no field for it, use the short version as a message to the hiring manager.
Should I link my GitHub if it is mostly empty?
No. Link the one or two things that support your letter, such as a merged pull request or a live project. An empty profile linked from a letter draws attention to the gap.
How long should a software engineer cover letter be?
One page and under 350 words as an upload; under 120 words when it goes into a text box or a message.
How do I mention a layoff in a cover letter?
In one neutral sentence with the month and the reason, such as an office closure, then move on to your work. Hiring managers have seen many layoffs and care far more about what you built.
What if the form asks for my salary expectations?
Give a range rather than one figure, and base it on the pay band in the advert if there is one. If there is no band, use what similar roles at similar companies advertise. The letter itself only needs a number if the advert asks for one there.
Should I name the technologies the company uses?
Only where you have used them for real, and inside a sentence about what you built. If you have not used their main language, say so and show the overlap that matters more, like the domain or the scale.