Module 6: Your Professional Materials in English
4. Tailoring Your Résumé to Each Job Posting
Description
There's an uncomfortable moment almost every developer lives through: you have a résumé that took you weeks to put together, you export it to PDF, and you send the exact same one to forty job postings. Silence. The temptation is to read that silence as a verdict on your English level or your talent. It almost never is. A generic résumé fails for a mechanical reason: the person reading it isn't looking for someone good "in general," they're looking for someone who solves the specific problem that made them open that posting in the first place. A one-size-fits-all document doesn't show them that match, and they don't have time to infer it for you.
Tailoring your résumé isn't writing a new one every time. It's a matching exercise: you take the posting, break it down into requirements, and for each requirement you point to the evidence you already have. Most of your bullets stay the same; what changes is the order, a handful of words, and sometimes two or three rewritten sentences. That's the entire difference between an application that gets lost and one that makes someone say "this person understood what I need." And there's a strategic decision layered on top: applying to many postings with little effort each, or to few with a lot. Both are valid, but not at the same moment in your search, and in this lesson you'll see plainly when each one makes sense.
Connection to the module: this module packages what you already know into the artifacts the market reviews before it talks to you. In the previous lesson you learned to write bullets that prove impact with the verb + what you did + result formula; here we're not rewriting that formula, we're using it: deciding which of those bullets move up, which move down, and which get fine-tuned for each posting. The input comes from module 1, where you analyzed real job postings to set your target role; now that analysis becomes a repeatable work tool. And everything you decide here feeds what comes next: the LinkedIn profile in the next lesson has to be consistent with the résumé you're fine-tuning right now.
The mistake of a hundred identical copies
Let's start by naming the mistake so we don't repeat it. The underlying belief is "the more I send, the better my odds." In raw numbers it sounds logical. In practice, a hundred identical submissions to a hundred different postings perform worse than ten tailored ones, and there's a concrete explanation for that, not a motivational one.
Your résumé passes through two readers before anyone calls you. The first is software (we'll look at it closely in a moment) that compares your résumé's text against the posting's text. The second is a person who spends seven to ten seconds deciding whether to keep reading or move to the next one. Neither one is evaluating who you are; both are evaluating how much you resemble what they asked for. A generic résumé is, by definition, the one that resembles any particular posting the least.
Tailoring doesn't mean lying or inflating. It means choosing, out of everything true you could say about yourself, what this posting needs to hear, and putting it where it gets seen first. Think of it like arranging a store's window display: you don't change the inventory, you change what's up front depending on who's about to walk in.
The correspondence map: requirement by requirement
This is the lesson's central technique, and it's simpler than it looks. A correspondence map is a three-column table where you translate the posting into an action plan: each requirement from the posting, the evidence you have backing it up, and the gap that's left when you don't have evidence. It's the same idea an engineer uses when reading a ticket: what's being asked, what already exists, what's left to build.
The first step is extracting the requirements. Every posting has them, even if they're buried in prose. Look for the section usually called Requirements, What you'll need, Must have, or Qualifications, and split each sentence into an atomic requirement. A line like "Experience building REST APIs with Python and a solid grasp of relational databases" is actually two requirements: REST APIs with Python, and relational databases.
With the requirements isolated, you fill out the table. Here's a real example for a junior backend posting:
| Job posting requirement (in English, as it appears) | Your evidence | Gap |
|---|---|---|
| Build and maintain REST APIs with Python | Bullet: Built a REST API with FastAPI serving 12 endpoints for a book-tracking app | — Covered |
| Work with relational databases (PostgreSQL) | Bullet: Designed a PostgreSQL schema with 6 tables and wrote the queries behind the app | — Covered |
| Familiarity with Docker | Project: the README mentions docker compose up | Partial: used it, don't have mastery |
| Experience with CI/CD pipelines | Nothing direct | Real gap |
| Good written communication in English | This résumé, my README, my profile | — Covered by the artifacts themselves |
What this table gives you isn't just clarity; it gives you decisions. The "Covered" requirements are the bullets that move up to the top of your résumé. The "Partial" ones can be mentioned honestly (we'll see how in a moment). And the "Real gap" is incredibly valuable information: it tells you what you're missing for this family of roles, not in the abstract. If the same gap (CI/CD, say) shows up in five postings in a row, you just found what to study next weekend. The correspondence map is, incidentally, your learning radar.
An honest warning about gaps: a gap isn't a disqualification. Almost no posting gets filled by someone who meets 100% of the requirements; job descriptions are wish lists. The practical rule a lot of hiring people use is that if you meet roughly 60% of the must haves, it's worth applying. The map lets you see that percentage instead of guessing it, and that alone lowers the anxiety of "am I enough or not?"
What to expect when you build your first map
The first time you do this, it's going to take you twenty to thirty minutes per posting, and it's going to feel slow. That's normal: you're building the habit of reading a posting as a technical document instead of a wall that intimidates you. By the fifth posting, the map takes you eight minutes, because a lot of requirements repeat across similar roles and you already have the evidence mapped from before. Don't throw those maps away: keep them. They become a personal library of "requirement → my best bullet" that you reuse.
Reordering and rewriting without inventing
With the map ready, tailoring the résumé comes down to two moves: reordering and rewriting. Neither one touches the truth of what you did.
Reordering is the cheapest and most powerful move. The person reading gives you seven seconds: almost all of it lands on the top third of the first page. So whatever the map flagged as "Covered" and most important for this posting has to be up there. If the posting screams "PostgreSQL" in every line, your PostgreSQL bullet can't be the fourth in a list of six; move it to first or second. You didn't delete anything, you didn't add anything: you just put what this posting came looking for at the front.
Rewriting means fine-tuning a bullet's wording so it speaks the posting's language, without changing the fact. Look at the difference:
Original bullet (true but neutral):
Created an API for a personal project using Python.
The posting literally asks for "design and build RESTful services." Rewrite (equally true, aligned to the vocabulary):
Designed and built a RESTful service in Python (FastAPI), exposing 12 endpoints with request validation and error handling.
We didn't invent anything: the project was always a REST API with FastAPI. What we did was name it with the words the posting uses (designed and built, RESTful service) and add the concrete detail that was already true but hadn't been written down. This is the opposite of inflating. Inflating would be writing "architected a scalable microservices platform" about that same single-service project; that collapses at the first technical interview question, and there you lose something more expensive than the posting: trust.
The line is easy to draw. Ask yourself: if in the interview they ask me to explain this bullet, can I hold it up for two minutes without turning red? If yes, the bullet is yours. If you have to pray they don't ask, it's invented and needs to come down.
The "Partial" case: honesty that adds up
Requirements you marked as "Partial" — things you touched but haven't mastered — can be included with language that's honest and still works in your favor. The trick is the verb's level of commitment:
| Real level | Verb/phrase in English | What it communicates |
|---|---|---|
| I've mastered it, used it seriously | Built, designed, implemented, deployed | Full ownership |
| I used it in a limited way | Used, worked with, integrated | Real contact, no exaggeration |
| I know it superficially | Familiar with, exposure to, basic knowledge of | Honesty about a basic level |
For the Docker example, where you only ran docker compose up, an honest bullet would be:
Containerized the app with Docker Compose for local development (familiar with, not production-hardened).
It sounds smaller, but it does two things: it plants the keyword Docker where the software will find it, and it presents you as someone who knows how to tell "I used it a little" from "I've mastered it." That distinction, for whoever's hiring, is a sign of maturity, not weakness.
Keywords: the posting's vocabulary (wherever it's true)
Here it's worth being precise, because this advice gets misread often. Using the posting's keywords isn't "stuffing terms to trick the software." It's naming what you did with the same words the company uses, so the reader — human or machine — recognizes the match without having to translate it.
The key, non-negotiable point is wherever it's true. If the posting asks for Kubernetes and you've never touched it, you don't put it. Period. But often you did do the thing and just called it something different. That's where the posting's vocabulary helps you:
| You wrote it as… | The posting calls it… | Is it true that it's the same thing? |
|---|---|---|
| Made a website with React | Built responsive UIs with React | Yes, if it genuinely is responsive |
| Connected to a database | Integrated with PostgreSQL | Yes, if the database was PostgreSQL |
| Fixed bugs | Debugged and resolved production issues | Only if they were in production; if not, resolved issues in the codebase |
| Wrote tests | Implemented unit tests with pytest | Yes, if you used pytest |
| Worked in a team | Collaborated in an Agile team using Git and pull requests | Only if it genuinely was Agile/PRs |
The right column is where the awareness of this operation lives. Adopting the posting's vocabulary is legitimate when it describes the same reality with a better name; it's fraud when it describes a reality you didn't live. The test stays the same: can I hold it up for two minutes in the interview?
A practical formatting detail: use keywords exactly as they appear in the posting, including capitalization and acronyms. If the posting says PostgreSQL, write PostgreSQL, not Postgres or postgre. If it says CI/CD, write CI/CD, not just continuous integration. The filtering software sometimes compares literally, and you don't want to lose points over an abbreviation. This is one of the few places where copying verbatim is the right move.
The short cover letter in English
The cover letter raises legitimate doubts: a lot of people believe nobody reads them anymore. The nuanced truth is that most postings don't ask for one, but when there's a field for it, or when you're applying directly by email to a person, a short, specific letter sets you apart from the pile of context-free applications. The honest rule: don't write a generic letter for everyone — that adds nothing and it shows. Write it only when you're going to genuinely tailor it, for postings you actually care about, in precision mode (we'll get to that at the end).
A good letter in technical English is short: four paragraphs, not one more, fitting in half a screen. Its job isn't to repeat the résumé, it's to connect three points: why this company, why you, and one concrete piece of proof. Here's the structure, paragraph by paragraph, with a template you can adapt:
Paragraph 1 — The specific hook. Name the role and one real reason this company interests you. Not "I've always admired your company" (empty), but something you'd only know if you looked:
I'm applying for the Junior Backend Developer role. I've been using your open-source library
Xin my own projects, and the way your team documents its APIs is exactly the kind of engineering I want to be part of.
Paragraph 2 — The match. One or two requirements from the posting connected directly to your evidence. Here you literally recycle the correspondence map:
Your posting asks for experience building REST APIs with Python and working with PostgreSQL. In my last project I designed and built a FastAPI service with 12 endpoints backed by a 6-table PostgreSQL schema — you can clone it and run it in under two minutes from the README.
Paragraph 3 — The gap, with honesty and eagerness. If there's an important requirement you don't meet, this is the place to defuse it yourself, before it becomes a silent objection:
I don't yet have hands-on experience with CI/CD pipelines, but I've read your engineering blog on the topic and set up a basic GitHub Actions workflow last week to start closing that gap.
Paragraph 4 — The close with action. Brief, cordial, no begging:
I'd be glad to walk you through the project or answer any questions. Thank you for your time and consideration.
Notice the tone: direct, concrete, with no empty superlatives like "I'm extremely passionate and hardworking." In technical English, passion gets shown with a specific detail, not declared with an adjective. Paragraph 3 is the scariest one to write and the one that sets you apart the most: showing that you know your gap and have already started closing it communicates exactly the maturity a company looks for in someone junior.
A note on your written English here: you write this letter with time, you revise it, and you can run it through a spellchecker. It doesn't have to come out perfect on the first try. It's writing, not live speech — it's exactly the terrain where your technical reading and writing level from module 3 is already more than enough. You don't need advanced conversational English to write four clear, revised paragraphs.
Volume versus precision: the honest strategy
Now for the underlying decision. Tailoring every résumé costs time, and your time is finite. There are two strategies, and the trap is believing one is "the correct one." Both work; at different moments.
| Volume strategy | Precision strategy | |
|---|---|---|
| What it is | Many applications, minimal tailoring (reordering + keywords) | Few applications, full map + rewritten bullets + letter |
| Time per posting | 5–10 minutes | 30–60 minutes |
| Typical response rate | Low per submission, but adds up in quantity | High per submission |
| When it makes sense | Early on: to calibrate the market, see what's asked for, generate practice interviews | For postings you genuinely want, or once your target role is clear |
| Risk | Burnout, discouraging silence | Few shots; if they miss, it hurts more |
The honest strategy isn't picking one forever, it's combining them in phases. At the start of your search, when you don't yet know well which role fits you or what postings really ask for, volume makes sense: every submission with light tailoring is also a market reading, and some responses serve as low-risk practice interviews. But volume without feedback turns into a discouragement machine: fifty silences in a row teach you nothing and wear you down.
That's why the goal is to migrate toward precision as you learn. Once your correspondence maps clearly tell you which family of roles fits you and where your gaps are, you move your energy to fewer, better-worked postings. A practical rule that works: reserve precision — full map, rewritten bullets, and letter — for the three to five postings you care about most each week, and handle the rest in volume mode. That way you don't burn out fine-tuning a hundred résumés or send a hundred dead copies.
And a reminder for linguistic impostor syndrome, because this is where it hits hardest: a posting's silence is almost never a verdict on your English. It's noise from a saturated process — hundreds of applications, automated filters, budgets that freeze. Your job isn't to decode every silence, it's to raise the probability with every tailored submission and keep going. Tailoring is, literally, the only thing in the whole process that's under your control. Use it.
Exercises
Exercise 1 — Reorder based on the posting.
You have these four bullets on your résumé, in this order:
- Wrote unit tests with pytest, reaching 70% coverage.
- Built a REST API with FastAPI serving 12 endpoints for a book-tracking app.
- Designed a PostgreSQL schema with 6 tables and wrote the queries behind the app.
- Set up a basic GitHub Actions workflow to run tests on every push.
The posting you're applying to says, in its first requirements line: "Strong experience with PostgreSQL and relational data modeling is a must." What order should these four bullets go in at the top of your résumé? Justify in one sentence why the first one goes first.
See solution
Suggested order: 3, 2, 1, 4.
Bullet 3 (PostgreSQL, schema design) moves to first place because it's exactly the requirement the posting flagged as a "must" in its first line — it's what the seven-second read needs to find first. Bullet 2 (the API itself) follows closely because it supports the project's context. Bullets 1 and 4 (tests and CI) move back because the posting doesn't mention them as a priority; they're still true and stay on the résumé, just not competing for the top spot. Why this works: reordering doesn't change any fact, it just puts what this particular posting came looking for at the front.
Exercise 2 — The honest verb for a "Partial."
In your real experience you used Redis exactly once, to cache a query in a personal project; you never configured it in production or touched it again. The posting asks for "Experience with caching layers (Redis or similar)." Write a one-line bullet that's honest about your real level and still mentions the keyword.
See solution
Something like: Used Redis to cache a frequent query in a personal project, cutting response time from 600 ms to 90 ms (familiar with, not production-scale).
Why this works: the verb used (not implemented or built) reflects the real level of commitment — one-off contact, not mastery —, the keyword Redis stays visible to the reader or the ATS, and the closing parenthetical is the same honesty you saw with the Docker example: it presents you as someone who knows how to tell "I tried it" from "I've mastered it," which is exactly the signal of maturity an inflated bullet can't give.
Exercise 3 — Legitimate match or invention?
For each pair, decide whether adopting the posting's vocabulary (on the right) is legitimate or an inflation of the truth, knowing the left column is what you actually did:
a) You did: "I wrote a few SQL queries for a report." → Posting asks for: "Optimized complex SQL queries for large datasets."
b) You did: "My project runs in a Docker container I set up following a tutorial." → Posting asks for: "Designed containerization strategy for microservices architecture."
See solution
a) It's invention if your queries weren't complex or didn't work with large datasets: optimized and large datasets promise something the interview question "how many rows did that table have?" is going to disprove on the spot. The honest version is closer to "Wrote SQL queries to generate a weekly report."
b) It's also invention: designed containerization strategy and microservices architecture describe architectural decisions that a single-container tutorial doesn't have. The honest version is the same one you already saw in the lesson: "Containerized the app with Docker Compose for local development (familiar with, not production-hardened)."
Why this works: the test is the same in both cases — can I hold it up for two minutes in the interview? — and in both cases the honest answer is no, so the posting's vocabulary doesn't get adopted as-is; it gets scaled down to what's actually defensible.
Exercise 4 — Volume or precision: choose the strategy.
You've been actively searching for two weeks, you've already sent thirty lightly tailored résumés, and you're starting to notice that "Junior Backend with Python" postings are the ones generating the most responses, while "Full Stack" ones almost never reply. Today a Junior Backend with Python posting shows up at a company you've been following for months and whose engineering blog you've already read. What strategy do you use for this specific posting, and why doesn't the same logic you used for your first thirty submissions still apply?
See solution
Precision: full correspondence map, rewritten bullets, and a four-paragraph letter. The early-weeks logic no longer applies because volume already did its job: it gave you market information and showed you your profile fits Junior Backend with Python better than Full Stack. Now that you have that clarity, and facing a posting where you genuinely care about the company, the extra time precision costs (30–60 minutes) has the highest return: it's exactly the type of posting the lesson's table flags as "the ones you genuinely want." Staying in volume mode here would waste the advantage you already built.
Summary and next step
Tailoring your résumé isn't rebuilding it, it's making visible the match between what you already know how to do and what this specific posting came looking for. It all comes from a three-column table and two honest moves: reordering so what's relevant sits up top, and rewriting with the posting's vocabulary wherever it's true. The short letter, when you write it in earnest, closes the loop by connecting company, evidence, and honesty about your gaps. And the volume-or-precision decision isn't philosophical: it's phase-dependent, and it evolves with you.
Before sending your next résumé, this quick checklist:
- Did I build the correspondence map? Requirement by requirement, with evidence and gaps flagged.
- Did I move up the bullets this posting needs most? The seven seconds land on the top third.
- Did I use the posting's keywords, verbatim, and only where they're true? Acronyms and capitalization included.
- Can I hold up every bullet for two minutes in an interview? If I have to pray, it comes down.
- Are "partial" requirements written with honest verbs (used, familiar with) and not inflated?
- If I wrote a letter, is it four paragraphs, specific, and does it defuse my main gap myself?
- Is this posting going in volume mode or precision mode? And did I choose deliberately, not by default?
With this, your résumé stops being a document you send into the void and becomes an answer to a specific question. Before moving on, you should be able to take any new job posting and, in under thirty minutes, produce your correspondence map, decide which bullets move up, and rewrite one or two with the posting's vocabulary — all without inventing anything you can't hold up in the interview. In the next lesson we bring this same coherence to your LinkedIn profile, so that whoever looks you up after the résumé finds the same story told just as well.
Resources
- Tailoring Your Resume — Indeed's guide on how to read a job posting and adjust your résumé accordingly, with rewriting examples.
- How to Write an ATS Resume That Lands Interviews — how tracking systems compare your résumé against the posting and how to integrate keywords without "stuffing" the text.
- Resumes, Cover Letters, Portfolios, and CVs — MIT's career center guide on tailoring your résumé and cover letter to each role.
- How to Write a Cover Letter: Your Full Guide (with Tips and Examples) — the complete structure of a short letter (header, opening, body, closing) with real examples.
- Why Women Don't Apply for Jobs Unless They're 100% Qualified — the origin of the 60%-of-must-haves figure that backs up why it's worth applying even with gaps left in the correspondence map.