Free lesson · The Job Search System
Writing a Cover Letter That Gets Read
Writing a Cover Letter That Gets Read
Student: Okay, I know when to write a cover letter. Now I need to know how to write one that actually works. What's the structure?
Swati: The structure is simpler than most people think. A cover letter has four parts, and if you hit all four clearly in 250 to 400 words, you're in the top 5% of cover letters hiring managers receive. I'm serious - the bar is that low, because most cover letters are generic templates.
Olena is joining us for this one because her cover letter to Zalando is the single best career-switcher cover letter I've ever read. She's going to walk you through it.
The Four-Part Structure
Every effective cover letter follows this structure:
graph TD
A["PARAGRAPH 1: The Hook<br/>Why THIS company specifically<br/>2-3 sentences, company-specific"] --> B["PARAGRAPH 2: The Bridge<br/>How your experience connects<br/>to what they need<br/>3-4 sentences"]
B --> C["PARAGRAPH 3: The Evidence<br/>Your strongest relevant<br/>accomplishment with a metric<br/>2-3 sentences"]
C --> D["PARAGRAPH 4: The Close<br/>Forward-looking, confident,<br/>specific ask<br/>1-2 sentences"]
style A fill:#7950f2,color:#fff
style B fill:#339af0,color:#fff
style C fill:#51cf66,color:#fff
style D fill:#fcc419,color:#000
This diagram shows the four-part cover letter structure. Paragraph 1 is The Hook - 2 to 3 sentences explaining why this company specifically. Paragraph 2 is The Bridge - 3 to 4 sentences connecting your experience to what they need. Paragraph 3 is The Evidence - 2 to 3 sentences with your strongest relevant accomplishment and a metric. Paragraph 4 is The Close - 1 to 2 forward-looking, confident sentences with a specific ask.
Let me break down each part.
Paragraph 1: The Hook - Why This Company
This is the paragraph that 95% of cover letters get wrong. They write something like "I am excited to apply for the Software Engineer position at CompanyX." That tells the reader nothing about why you're applying to CompanyX rather than CompanyY or CompanyZ.
The hook should be specific enough that it could only apply to this one company. If you could swap the company name and the paragraph still works, it's not specific enough.
Bad hook: "I am writing to express my interest in the Backend Engineer position at Stripe. With my experience in distributed systems, I believe I would be a strong addition to your team."
Good hook: "After reading your engineering blog post on idempotency in payment systems, I realized that the retry-handling challenges your team described are nearly identical to the ones I solved when building the transaction reconciliation pipeline at my current company. I'd love to bring that experience to Stripe's Payments Infrastructure team."
The good hook does three things: references something specific about the company (the blog post), connects it to the candidate's experience (retry handling), and names the specific team. The hiring manager reads this and thinks "this person actually knows what we do."
Student: How do I find company-specific things to reference?
Swati: Four sources:
-
Engineering blog. Most tech companies publish engineering blogs. Read the last 3 to 5 posts. Find one that connects to your experience. Companies like Stripe, Netflix, Uber, Airbnb, and Meta all have excellent engineering blogs.
-
The job description itself. The JD describes specific technical challenges. "You'll design systems that handle 10M+ daily events" - reference that directly. "I've built event processing systems at similar scale, and I know the trade-offs between batch and streaming approaches you're likely evaluating."
-
The product. Use the company's product. Sign up. Play with it. Notice something interesting about how it works. "I noticed your real-time collaboration feature handles conflict resolution smoothly even on unstable connections - I'd love to understand the CRDT implementation behind it."
-
Recent news or announcements. Company launches, funding rounds, acquisitions, open source releases. "I saw that you open-sourced your internal feature flagging system last month - the design decisions in the README align closely with the approach I took when building a similar system at my current company."
Paragraph 2: The Bridge - How Your Experience Connects
The bridge paragraph connects your background to what the company needs. This is where you translate your experience into their context.
Student: How is this different from the resume?
Swati: The resume presents your experience in YOUR framing. The bridge paragraph presents your experience in THEIR framing. You're not listing what you've done - you're explaining why what you've done is relevant to what they need.
For a standard engineering application: "In my current role at DataCorp, I've spent three years building event-driven microservices that process financial transactions at scale - exactly the kind of systems your Payments Infrastructure team works on. I've dealt with the same challenges your blog post described: ensuring exactly-once processing, handling partial failures gracefully, and maintaining sub-200ms latency under peak load."
For a career switcher: "My four years as a financial analyst at PwC taught me to work with complex data systems, communicate technical concepts to non-technical stakeholders, and deliver under pressure. When I transitioned to software engineering, I brought those analytical skills into my technical work - my first production application automated a reporting process that three analysts had previously done manually."
For a returner: "Before my career break, I spent seven years building distributed systems at Amazon. During the past year, I've re-engaged with current technologies - building a Kubernetes-deployed microservices application and contributing to two open-source projects. My production experience combined with current technical skills positions me to contribute immediately."
Paragraph 3: The Evidence - One Strong Accomplishment
This is not a summary of your resume. It's ONE specific accomplishment - the one most relevant to this role - described with enough context and metrics to be credible.
Student: Why just one? Shouldn't I show range?
Swati: Your resume shows range. The cover letter shows depth. One carefully chosen example, described in 2 to 3 sentences with a real metric, is more persuasive than a list of five accomplishments mentioned briefly.
Good evidence paragraph: "The most relevant example: at DataCorp, I designed and built a transaction reconciliation pipeline that processes 2M daily events and automatically detects and resolves 97% of discrepancies without human intervention. Before this system, reconciliation required 3 full-time analysts and took 48 hours. Now it runs in 12 minutes. The architectural decisions I made there - event sourcing, compensating transactions, and idempotent retry logic - are directly applicable to the challenges described in your posting."
That paragraph gives the hiring manager a concrete example with metrics, technical details, and an explicit connection to their needs. It answers the question "Can this person do the job we're hiring for?" with evidence, not claims.
Paragraph 4: The Close - Confident and Specific
The close should be confident, forward-looking, and short. Don't grovel. Don't be passive. State what you want.
Bad close: "I would be grateful for the opportunity to discuss how my skills might potentially be a fit for your team. Thank you for your valuable time and consideration."
Good close: "I'd welcome the chance to discuss how my experience with event-driven systems maps to your Payments Infrastructure challenges. I'm available for a conversation anytime this week or next."
The good close is specific (references the team and domain), confident (doesn't hedge with "might potentially be"), and actionable (suggests next steps with a timeframe).
Olena's Cover Letter Story
Olena: Let me tell you about the cover letter that changed my career. When I applied to Zalando in London, I was a 28-year-old former financial analyst who had been coding for about a year. My resume was thin on engineering experience. Without a cover letter, I was a confusing application - finance background, self-taught coder, no CS degree, no tech company names.
Student: What did your cover letter say?
Olena: I used exactly the four-part structure Swati described. Here's the approach I took for each part - I won't give you the exact words, but I'll give you the strategy:
My hook: I referenced Zalando's tech blog post about their fashion recommendation algorithm. I said I'd been reading their engineering blog for months, and as someone who had spent four years analyzing consumer behavior data at PwC, the intersection of data analysis and e-commerce technology was exactly where I wanted to build my engineering career. This was specific to Zalando - it couldn't have been sent to any other company.
My bridge: I connected my financial analysis experience to engineering. I explained that I'd spent four years building complex data models, automating reporting workflows, and making decisions under uncertainty. I said these skills - analytical thinking, data fluency, communication - were the same skills I was now applying to software engineering. I framed my career switch as an evolution, not a departure.
My evidence: I described the one project I was proudest of - a full-stack e-commerce analytics dashboard I'd built from scratch using React and Node.js. I included the metrics: the dashboard processed data from 50K simulated transactions, had a real-time updating UI, and was deployed on Heroku with CI/CD. For a self-taught engineer, that was meaningful evidence of capability.
My close: I said I understood that hiring a career switcher was a risk, and I wanted to address that directly. I said my learning velocity was my strongest asset - I'd gone from zero coding experience to a deployed full-stack application in 8 months, and I'd bring that same intensity to contributing at Zalando.
Student: And they called you?
Olena: They called me within a week. The interviewer opened by saying "I really liked your cover letter." That doesn't happen often, and it confirmed something I already suspected: for a career switcher, the cover letter isn't optional. It's the document that makes the resume make sense.
Important: For career switchers: your cover letter is more important than your resume. Your resume shows skills and projects, but it raises questions - why the career change? Can you really do this? Are you committed? The cover letter answers all of those questions proactively. Without it, the hiring manager fills in the blanks with skepticism. With it, they fill in the blanks with your story.
The Tone Question
Student: How formal should a cover letter be?
Swati: Match the company's voice. Read their careers page, their engineering blog, and their JD. If the JD says "we're a scrappy team that ships fast and breaks things," your cover letter should sound conversational and direct - not stiff and corporate. If the JD says "we seek candidates with a demonstrated commitment to engineering excellence," your cover letter should be more polished.
In general, tech cover letters should be conversational-professional. Think of it as an email to a senior engineer you respect but don't know well. Not a legal brief. Not a text message. Somewhere in between.
Student: First person or third person?
Swati: Always first person. "I built..." not "The candidate built..." You're a person, not a document.
graph TD
A["Cover Letter Tone"] --> B{"What's the company<br/>culture like?"}
B -->|"Startup, informal,<br/>'move fast'"| C["Conversational<br/>'I saw your product and...'<br/>'Here's what I'd bring...'"]
B -->|"Enterprise, structured,<br/>'engineering excellence'"| D["Professional-polished<br/>'My experience in X positions<br/>me to contribute to Y...'"]
B -->|"Not sure"| E["Default: conversational-<br/>professional<br/>Warm but not casual"]
style C fill:#51cf66,color:#fff
style D fill:#339af0,color:#fff
style E fill:#fcc419,color:#000
This decision tree helps determine the right cover letter tone. If the company culture is startup, informal, or move-fast, use a conversational tone. If the company culture is enterprise, structured, or emphasizes engineering excellence, use a professional-polished tone. If you're not sure, default to conversational-professional - warm but not casual.
Warning: Avoid these tone traps:
- Over-humble: "I know I may not have all the qualifications, but I hope you'll consider me..." - This undermines your candidacy before the reader has evaluated you.
- Over-confident: "I am the ideal candidate for this role and I guarantee results." - This sounds arrogant and ungrounded.
- Overly casual: "Hey! Saw your posting and thought it looked pretty cool!" - Unless the company's entire brand is hyper-casual, this feels unprofessional.
- Overly formal: "Pursuant to the posting for a Software Engineering position, I hereby submit my candidacy..." - Nobody writes like this anymore.
Common Mistakes and How to Avoid Them
Mistake 1: Writing a different cover letter for the resume and the email. If you're emailing your application, your email IS the cover letter. Don't write a formal cover letter as an attachment and then repeat it in the email body. One version, in the email body, with your resume attached.
Mistake 2: Apologizing for what you lack. "I know I don't have experience with Kubernetes, but I'm a fast learner." Don't lead with what you're missing. Lead with what you bring. If you don't have Kubernetes experience and it's a core requirement, this might not be the right role - or address the gap indirectly by mentioning adjacent experience ("I've deployed production systems on Docker and AWS ECS, and I'm currently completing CKA certification").
Mistake 3: Including your life story. The cover letter is not an autobiography. It's 250 to 400 words. Your childhood passion for computers, your college thesis, and your career journey from age 18 to today don't all need to be here. Pick the thread that matters most for THIS application and follow it.
Mistake 4: Not proofreading. A typo in a cover letter is worse than a typo on a resume. The cover letter is shorter, every word is more visible, and the document's entire purpose is to demonstrate communication quality. Proofread it. Then proofread it again. Then have someone else proofread it.
Tip: The "Would I Send This to My Manager?" Test: Before sending a cover letter, ask yourself: "If my current engineering manager received this letter, would they think it was well-written and professional?" If yes, send it. If no, revise. Your current manager represents the caliber of reader who will evaluate your cover letter - a senior technical leader who values clarity and substance over formality.
Interview: The Cover Letter to Interview Pipeline
When a hiring manager reads your cover letter before the interview, they arrive with context. They know why you're interested. They know your transition story. They know which of your accomplishments you consider most relevant. This means the interview starts at a higher level - instead of spending 5 minutes establishing basics, you can dive directly into technical depth.
Prepare for this by re-reading your cover letter before every interview. Know what you said. Be ready to expand on it. If you referenced a specific engineering challenge at the company, have a thoughtful perspective on it ready. The cover letter opened the conversation - the interview continues it.
Exercise: Starter: Using the four-part structure (Hook, Bridge, Evidence, Close), write a cover letter for a company you'd genuinely like to work at. Keep it to 300 words. Time yourself - it should take about 25 minutes for the first draft, including 10 minutes of research for the hook paragraph.
Intermediate: Write two cover letters for two different types of companies - one startup and one large company. Compare the tone, the hook, and the level of detail. Notice how the structure stays the same but the voice and content adapt. This is the skill of code-switching in written communication, and it's directly applicable to professional engineering communication.
Advanced: Exchange cover letters with a friend or peer. Read each other's and answer honestly: (a) Does the hook make you want to keep reading? (b) Can you tell which specific company this was written for? (c) Is there one clear accomplishment with a real metric? If any answer is "no," revise together. Peer review is as valuable for cover letters as it is for code. You can also share drafts in the AlgoInsight Discord for community feedback.
Student: I've never written a cover letter with this much intention. It's actually kind of like engineering - there's a clear structure, each part has a specific job, and the output is judged on clarity and precision.
Olena: That's exactly right. And that's why good engineers tend to write good cover letters once they learn the structure. The analytical thinking you use every day in code reviews and design docs is the same thinking that makes a cover letter effective.
Swati: Module 03 is done. You now know when to write a cover letter and how to write one that gets read. In Module 04, we're moving to the second layer of your discoverability stack - LinkedIn. Olena is going to lead that module because she's the team's product expert, and LinkedIn is fundamentally a product optimization challenge.
Let's keep building.