How to Write a Cover Letter That Doesn't Waste the Hiring Manager's Time
TL;DR - Most cover letters for software engineering roles are skipped or do active damage. - They matter most at small companies, for direct applications, and for roles where context helps (career changers, unusual backgrounds). - The structure is three paragraphs: why this company, what you can do, a clear ask. - The mistakes that kill cover letters: generic openers, restating the resume, focusing on what you want from them. - Write it for the reader, not for yourself. - A 200-word cover letter that shows specific interest beats a 600-word essay about your passion for technology.
Cover letters are the most debated part of a software engineering application. Hiring managers disagree on whether to read them at all. Candidates spend hours on letters that get opened for ten seconds or not at all.
Here's the honest view: a good cover letter rarely makes the difference between a rejection and an interview. A bad cover letter can absolutely cost you one. That asymmetry tells you how to think about it.
When a cover letter actually matters
At most large tech companies, cover letters are optional fields that automated systems and junior recruiters often skip. By the time an engineering manager or technical recruiter is reading your application, they've already decided you're worth looking at based on your resume and portfolio.
But there are situations where a cover letter does real work:
Small companies with direct hiring. When a founder or a single hiring manager reads every application, they read cover letters. A direct, specific letter signals that you did your homework. An absent or generic one signals that you're applying to fifty companies and don't care which one responds.
Direct-to-recruiter or direct-to-engineer outreach. When you're not going through an ATS and instead sending materials directly to a person, the cover letter is the beginning of a conversation. It needs to read that way.
Career changers and non-traditional backgrounds. If your resume doesn't immediately tell a coherent story, a cover letter gives you a place to tell it briefly. This is one of the few cases where the letter carries real explanatory weight.
Roles where motivation matters. Mission-driven organizations, small nonprofits, early-stage startups, and specific technical teams sometimes care why you want the job. For those, a cover letter that shows you actually understand what they're building is a meaningful signal.
Roles with specific requirements. If a job posting lists something unusual, like experience with a rare tool, comfort with a particular domain, or a preference for location, a cover letter that directly addresses those points helps.
If none of these apply, a clean short letter is still worth writing. It takes twenty minutes if you have a good template, and it won't hurt you if it's done right.
What kills a cover letter
Before getting to structure, it's worth cataloging what makes a cover letter actively bad. Most of these mistakes are common enough that you've probably seen them (or written them).
Generic openers. "I am excited to apply for the Software Engineer position at your company." Nobody has ever been hired because of that sentence. It tells the reader nothing, and it signals that the rest of the letter will be equally thin.
Restating the resume. "As you can see from my attached resume, I have two years of experience with JavaScript and have built three full-stack applications." They can see that. The cover letter is not a verbal summary of the resume.
Leading with what you want. "I am looking for an opportunity to grow my skills in a collaborative environment." This is the most common mistake in junior cover letters. You're telling the reader what you want from them. They don't owe you skill development. Lead with what you bring.
Flattery without specifics. "I have always admired [Company] for its culture of innovation and commitment to excellence." This is filler that reads as filler. Everybody admires the company they're applying to. Saying so without specifics is the cover letter equivalent of saying "I'm a hard worker."
Too long. Three paragraphs. Maybe four if there's a real reason. Most cover letters are too long because candidates mistake length for seriousness. A reader who has already decided the letter is going somewhere has better things to do than read paragraph seven.
The three-paragraph structure
This structure works. It's not creative, but creative is rarely what gets you hired. Clear and specific is what gets you hired.
Paragraph 1: Why this company
Not why you want a job. Why this specific company.
This requires you to actually know something about the company. Not their About page. Something real: a product decision they made, a technical blog post their team published, a direction they're heading that connects to work you've done or care about.
This paragraph should be two to four sentences. It demonstrates that you researched them and have a point of view.
What it should not be: a list of the company's achievements ("your product has X million users and you've raised Y rounds of funding"). They know. You're not telling them anything.
A good version: "I've been following [Company]'s work on [specific thing] for the past year. The way your team approached [technical or product problem] in [a specific context] is the kind of problem I want to work on. That's why I'm applying for this role specifically, not just as another application."
Paragraph 2: What you can do
This is the one place where your experience is directly relevant to their needs.
Don't list everything you know. Pick one or two things that connect specifically to what they're hiring for. Link your work to their problem. This is the part of the letter where specificity about the role matters.
A weak version: "I have experience building web applications using React, Node, and PostgreSQL, and I am comfortable working in an Agile environment."
A stronger version: "In my last project I built [specific thing] that handled [specific problem]. Reading through your job posting, it looks like that's close to what [role] will be doing in the first quarter. I've shipped that kind of work before and I know the tradeoffs."
You don't have to be exact. You should be as specific as you can be given what's public about the company.
Paragraph 3: The clear ask
This paragraph should be three sentences or fewer.
Say directly what you'd like to happen next. An interview. A conversation. Whatever fits the context.
Don't hedge. "I would love the opportunity to chat if you feel I might be a fit" is weaker than "I'd welcome a conversation about the role. I'm available any time next week."
End it. Don't trail off into "Thank you for your time and consideration of my application." Just: "Looking forward to hearing from you" or nothing at all.
A complete example
Here's a short example that follows the structure. This is for a mid-stage B2B software company with a small engineering team.
I've been watching how [Company] approaches its data pipeline architecture, particularly the way you've handled multi-tenant isolation at scale. That's a problem I've spent a lot of time on, and your engineering blog's writeup on the tradeoffs between row-level security and schema-per-tenant helped me think through a decision I was working through at the time.
The backend work in this role maps closely to what I've been building. In my most recent project I built a multi-tenant API that handled [specific constraint], which required me to work through [specific decision]. I can bring that directly to what your team is doing right now.
I'd like to talk about the role. I'm available any time this week or next.
That's under 180 words. It has a specific reason for applying, a direct connection to their work, and a clear ask. It won't get ignored.
Adapting for specific situations
Career changer: The first paragraph is where you briefly address the transition. "My background is in [previous field]. Over the past 18 months I've been building [specific technical work]. The reason I'm applying to [company] specifically is [concrete reason]." That's it. Don't over-explain the career change.
Bootcamp graduate: The cover letter is not the place to justify your training. Address the company, address what you can do, make the ask. If your resume presents your background clearly, the letter doesn't need to re-litigate it.
Applying to a very large company: These often go into an ATS with no human reading cover letters at first pass. Keep it short, don't skip it entirely, but don't spend two hours on it.
Following up on a referral: Mention the referral in the first sentence. "I was referred by [name], who works on [team/role]." That one sentence changes how the letter gets read.
The time investment question
If a cover letter takes you two hours, you're overthinking it. The goal is not a literary achievement. It's a signal that you are serious about this specific job.
For most applications, thirty minutes is enough if you have the structure down. A template where you swap out the company-specific sections in paragraph one and adjust paragraph two takes even less time. Don't let perfect be the enemy of sent.
The more important question is whether you're writing cover letters for applications that warrant them. Applying to 80 companies and writing 80 custom cover letters is a time sink that probably isn't worth it. Writing a specific, strong cover letter for 10 targeted applications is a different calculation. Why mass-applying doesn't work covers the broader tradeoffs in that decision.
Cover letters matter in specific contexts and not much in others. The goal isn't to write a cover letter. The goal is to get an interview. The letter is one piece of that. Make sure your resume is doing most of the work first. The software engineering resume guide covers what actually moves the needle there.
For how recruiters read what you send them, see what recruiters see in 10 seconds. It changes how you prioritize every part of your application.
If you want structured support with job application strategy, here's how the Globally Scoped program works.
Interested in the program?