Module 1: The Market Reality and Your Target Role
3. Anatomy of a Job Description
Description
An English job description looks like an intimidating wall of text, but it's actually a format with fixed pieces that always show up in the same order. Once you know the pieces, you stop reading it as if every word were an English exam and start reading it for what it is: a business document that tells you who the company is looking for, what problem they want solved, and how flexible they are about what they're asking for. Most Spanish-speaking developers who self-reject don't do it for lack of technical skill: they do it because they read a list of fifteen requirements, counted how many they didn't meet, and closed the tab. This module exists so that doesn't happen to you again.
In this lesson we're going to open up a job description and break it into its blocks: about the role, responsibilities, requirements, nice to have, benefits, and that legal paragraph at the end almost nobody reads. You'll learn to tell what's mandatory apart from what's a wish list, why applying while meeting 60-70% of the requirements is normal rather than a trap, and how certain words — own, drive, mentor, support, contribute to — tell you the real seniority of the role even when the title says something else. You'll also learn to recognize when a job posting is well written because there's a concrete problem behind it, and when it's generic text the company copy-pasted.
An honest note before we go on, and it applies to the whole guide: this doesn't teach you English from zero. We assume you already read technical English with effort — that you can follow a README, a Stack Overflow answer, or a library's documentation, even if you look up the odd word in the dictionary. If reading an English job posting line by line feels impossible, the honest path is to build up general reading English first and come back here after; this lesson will serve you far better then. Decoding a job posting is exactly the kind of technical reading that's within reach for you right now.
Connection to the module: In the previous lesson you saw where the cut happens — before your code, in the reading of your resume and in the first minutes of a call — and how your access to job postings changes with your English level. Now we go to the first document you run into in that process: the job posting itself. Knowing how to read it is the indispensable step before the module's project, your target role brief. You can't decide which role you're aiming for if you don't know how to read what each role is actually asking for.
The myth we need to break first
There's a belief that costs thousands of developers their interviews: "if I don't meet every requirement, I shouldn't apply." It's false, and companies themselves know it. A job description isn't a contract or a checklist of verifiable minimums: it's a description of the ideal candidate, who probably doesn't exist. Recruiters and hiring managers say it openly on LinkedIn every week: if you meet 60% to 70% of the requirements, and the ones you're missing aren't the core of the role, apply.
The key word is core. Not every requirement carries the same weight. A job posting mixes, in the same list and without warning you, non-negotiables ("you need to know how to code in Python") with nice-to-haves ("it would be great if you knew Kubernetes"). Your job when reading isn't to count requirements: it's to separate the must-have from the wish list. That's what we're doing here.
What to expect: After this lesson you'll read a job posting in two or three minutes and walk away with a clear decision — apply, don't apply, or apply while tailoring your resume — instead of that fuzzy feeling of "I don't know if I'm good enough." That fuzzy feeling is exactly what this lesson eliminates.
The fixed structure of a job posting
Almost any job description in English, whether from a startup or a large company, follows the same skeleton. The headers for each block vary a little, but the function of each one is always the same. This is the table I want you to memorize:
| Block (in English) | What it really is | How to read it |
|---|---|---|
| About the company / About us | Marketing. Who they are, their mission. | Skim it. It only matters for your cover letter and for questions at the end. |
| About the role / The opportunity | The one-sentence summary of what you'll do and who you report to. | The real seniority is hidden here. Read it closely. |
| Responsibilities / What you'll do | Your day-to-day if you get hired. | The best predictor of the role. More honest than the title. |
| Requirements / What we're looking for / Must-haves | What they think you need. Mixes must-have and wish list. | Separate it yourself. This is where you decide whether to apply. |
| Nice to have / Bonus points / Preferred | An explicit wish list. | Zero of these is mandatory. Not one. |
| Benefits / What we offer / Perks | What they give you. Salary, sometimes. | Your filter: remote, salary band, time zone. |
| Equal opportunity statement | Legal anti-discrimination paragraph. | Doesn't tell you anything about the role, but its absence says something (more on that below). |
Notice something: the block that scares people the most — requirements — is the fourth one, not the first. By the time you get there, about the role and responsibilities should have already told you whether the role fits your size. Many candidates jump straight to the requirements list, get scared, and never read the responsibilities, which is the most revealing part.
Let's go block by block with real language.
Block by block, with real English
About the role — where seniority hides
This short paragraph defines the role. Compare these two opening lines, pulled from the same type of "Backend Engineer" posting:
"We're looking for a Backend Engineer to own our payments platform and drive the technical roadmap for the team."
"We're looking for a Backend Engineer to contribute to our payments platform and support the team in shipping features."
Notice the nuance: the first one has you owning the payments platform and driving the technical roadmap; the second has you contributing to the platform and supporting the team in shipping features. Same title — Backend Engineer — two completely different jobs. The first is a senior role with autonomy and decision-making responsibility; the second is a support role, probably mid or even junior, where someone else decides and you execute.
The job title lies often; the verbs don't. This is the seniority verb table you want in your head:
| Verb / phrase (English) | Plain-English meaning | Seniority it signals |
|---|---|---|
| own (a system, a domain) | sole owner of, accountable for | Senior. You're the one accountable. |
| drive (the roadmap, adoption) | pushes forward, sets the direction of | Senior. You set the direction. |
| lead / mentor | leads / mentors others | Senior or lead. You guide others. |
| define / shape | defines / gives shape to | Senior. You decide the "what." |
| contribute to | adds to, plays a part in | Mid. You contribute, you don't decide. |
| support / assist | supports / assists | Mid or junior. You help. |
| help (the team) with | helps (the team) with | Junior/mid. Support role. |
| learn / grow | learns / grows | Junior. They expect to train you. |
| collaborate with | collaborates with | Neutral. Shows up everywhere. |
How to use this: If the role is described with own, drive, lead, define, and you have two years of experience, it's not that you "can't" apply — it's that you'll probably be measured against someone with five or more years, and the interview will assume an autonomy you haven't exercised yet. It doesn't bar you from applying; it warns you where the bar is. If the role is described with contribute, support, help, learn, and you already have six years of leading experience, the signal runs the other way: it might be a role below your level (and your salary).
Responsibilities — the most honest block
Responsibilities (or What you'll do) is the list of what you'll actually do. It's more reliable than the title because it describes concrete activities, not aspirations. Real example:
What you'll do:
- Design, build, and maintain RESTful APIs used by millions of requests per day
- Collaborate with product managers to translate business needs into technical solutions
- Participate in code reviews and mentor junior engineers
- Take part in the on-call rotation
Two details here should change your decision: "mentor junior engineers" confirms this is a mid-to-senior role, and "on-call rotation" tells you there are on-call shifts — stretches of time when you're expected to be reachable outside business hours if something breaks in production. That doesn't show up in the title or the salary, but it defines your quality of life. Learning to spot details like these is worth as much as the English itself.
Requirements — separating the must-have from the wish list
This is where people self-reject. The trick is that companies rarely label what's mandatory and what's optional: they hand it all to you in a single list. But the language gives away the weight of each line. Look at these modifiers:
| Phrase in English | Real weight | Signal |
|---|---|---|
| "You must have…" | Non-negotiable | Pure must-have. |
| "Strong experience with X" | Core | Must-have. Be ready to demonstrate it. |
| "Solid understanding of…" | Core | Conceptual must-have. |
| "Experience with X" (plain) | Important | Nearly must-have. |
| "Familiarity with…" | Nice to have | Having touched it once is enough. |
| "Exposure to…" | Nice to have | You saw it once, that's enough. |
| "Bonus if…" / "A plus" | Optional | Wish list. Zero weight. |
| "Nice to have…" | Optional | Explicit wish list. |
An example to practice your eye. This requirements list:
- 3+ years of experience building backend services in Python or Go
- Strong understanding of relational databases and SQL
- Experience with cloud platforms (AWS, GCP, or Azure)
- Familiarity with Docker and Kubernetes
- Exposure to event-driven architectures is a plus
Decoded: the first two are genuine must-haves — 3+ years and strong understanding leave no wiggle room. The third (experience with) is nearly mandatory but accepts any of the three clouds, so knowing just one is enough. The fourth says familiarity: having spun up a Docker container once already qualifies you, you don't need to be a Kubernetes expert. The fifth ends in is a plus: it's wish list, it counts for nothing in your decision.
Result: if you're solid in Python or Go and SQL, have touched one cloud, and have used Docker at some point, you meet the core even though your naive count says "I only have 3 of 5." That's exactly the difference between applying and not applying.
The 60-70% rule, in practice: count only the must-haves (the lines with must, strong, solid, or years of experience). If you meet most of those, apply, even if every single nice to have is missing. The wish list is there for the fantasy candidate; nobody meets all of it.
Nice to have — explicit permission to not know everything
This block is a gift almost nobody knows how to read. When a job posting separates nice to have from requirements, the company is telling you flat out: "this is not mandatory." Headers you'll see: Nice to have, Bonus points, Preferred qualifications, It would be great if you…. Everything hanging under one of these is zero-mandatory. If a skill you don't have shows up under this header, cross it off your list of fears mentally.
Benefits — your filter, not theirs
Here you read for what matters to you: work mode (remote, hybrid, on-site), time zone (must overlap 4 hours with US Eastern time), and sometimes the salary band. Vocabulary worth recognizing on sight:
| In English | What it means for you |
|---|---|
| Fully remote | 100% remote. |
| Remote (US only) / (EU only) | Remote but with a geographic filter. May rule you out. |
| Hybrid, 3 days in office | Partly on-site. If you don't live there, cross it off. |
| Must overlap with PST/EST/CET | You're asked to overlap hours with that zone. Check your own time zone. |
| Competitive salary | They're not saying how much. A sign you'll have to ask. |
| Salary range: $X–$Y | Transparency. Usually a more mature company. |
Time zone and geographic filters decide more rejections than English does. A fully remote posting that says (US only) in the fine print isn't for you even if your English is perfect — and it's better to find that out in the benefits block than after three interviews.
Equal opportunity statement — the paragraph you read by its absence
The legal paragraph at the end ("We are an equal opportunity employer and do not discriminate on the basis of…") doesn't add anything to the content of the role. But its presence or absence is a weak signal of maturity: large companies and serious startups almost always include it. Don't use it to decide, but note it as a context clue about how formal the process ahead of you is likely to be.
A posting with a real problem vs. a generic posting
Not every job description is worth your time. Learning to smell out a generic posting — copied, empty, written by someone who doesn't understand the role — saves you from applying into black holes. Compare:
Generic (skip it or apply with low expectations):
"We are looking for a rockstar/ninja developer who is passionate about technology and can wear many hats in a fast-paced environment. Must be a self-starter and a team player with excellent communication skills."
All of that — rockstar, ninja, wear many hats, fast-paced, self-starter, team player — is filler. It doesn't say what you'll be building, for what product, or what problem the team solves. "Wear many hats" usually means "we don't have real processes yet and you'll be doing a bit of everything." That's not an instant disqualifier, but read it knowing the company doesn't fully know what it needs yet.
With a concrete problem behind it (this one's worth it):
"Our data pipeline processes 2 TB per day and currently takes 6 hours to run. You'll redesign it to run in under 1 hour. You'll work with our two data engineers and own the migration from batch to streaming."
In plain terms: their pipeline processes 2 TB a day and takes 6 hours to run; you'll redesign it to run in under an hour; you'll work with two data engineers and own the migration from batch to streaming. There's a real, measurable, specific problem here. This kind of posting is gold for three reasons: you know exactly what's expected of you, you can prepare for the interview around that problem, and a company that writes like this usually has clearer processes.
| Sign of a generic posting | Sign of a posting with a real problem |
|---|---|
| rockstar, ninja, guru | A named, measured technical problem |
| wear many hats, fast-paced | Concrete numbers (scale, timing, volume) |
| A list of 15+ technologies with no focus | 3-5 core technologies, prioritized |
| Neither the product nor the team is named | The product, the team, the challenge are named |
| Identical copy across three of the company's postings | Text clearly written for this role |
Exercises
Before you apply the template to real job postings (that's in the next block), calibrate your eye with four already-trimmed fragments. Write your answer first, and only open the solution after.
Exercise 1 — Read seniority in the verbs, not the title
This posting's title just says "Backend Engineer." Read the about the role and decide what real seniority it signals. Justify it with the verbs.
"As a Backend Engineer, you'll help the team build new features, support the migration to microservices, and learn our codebase alongside senior engineers who will mentor you."
See solution
Real seniority: junior. The verbs give it away: help, support, learn, and "senior engineers who will mentor you" — here you're the mentee, they're going to train you. None of them are own, drive, lead, or define. The title "Backend Engineer" is neutral, but the language describes someone who executes and learns, not someone who decides.
Why this works: when the title doesn't mark a level, the verbs do; the combination of help / support / learn plus "will mentor you" sets the interview bar at junior, not senior.
Exercise 2 — Separate the must-have from the wish list and count only the core
Classify each line as must-have or wish list. Then answer: should a candidate with 4 years in Java, who understands distributed systems and has used AWS, but never touched Kafka or Terraform, apply?
- You must have 4+ years of experience with Java or Kotlin
- Solid understanding of distributed systems
- Experience with any major cloud provider
- Familiarity with Kafka or other message queues
- Exposure to Terraform is a plus
- Nice to have: contributions to open source
See solution
Must-have (3): you must have 4+ years (non-negotiable), solid understanding (conceptual core), experience with any major cloud provider (nearly must-have, and "any" lets you pick whichever cloud you already know). Wish list (3): familiarity with Kafka (nice to have), exposure to Terraform is a plus (optional), nice to have: open source (explicitly optional).
The candidate meets 3 of 3 must-haves → apply without hesitation. Kafka, Terraform, and open source are all nice-to-haves; missing them doesn't count against you.
Why this works: a naive count would say "I meet 3 of 6" and scare you off; counting only the core (lines with must, solid, or years of experience) reveals a 100% match on what actually carries weight.
Exercise 3 — Generic, or a real problem behind it?
Mark which of the two is generic and which has a concrete problem behind it. Give one signal for each.
A: "We need a rockstar full-stack ninja who thrives in a fast-paced environment, wears many hats, and is passionate about disrupting the industry."
B: "Our checkout page loads in 3 seconds and has a 12% cart-abandonment rate. You'll lead the front-end rewrite in React to bring load time under 1 second, working with one designer and one backend engineer."
See solution
A is generic. Signals: rockstar, ninja, fast-paced, wears many hats, disrupting the industry — pure filler. It names no product, no team, no problem, no number.
B has a real problem. Signals: measurable numbers (3 seconds, 12%, under 1 second), a named product (checkout page), a named team (one designer and one backend engineer), and a clear seniority verb (lead).
Why this works: posting B lets you prepare for the interview around a measurable problem and you know who you'll be working with; A doesn't even tell you what you'd be building, so you'd be applying blind.
Exercise 4 — Benefits: the fine print that disqualifies you
You're a developer in Spain. Read the benefits block and decide whether the posting is viable for you. Which two lines are the deciding ones, and why doesn't "fully remote" settle it?
"Fully remote. Competitive salary. You must overlap at least 5 hours with US Pacific Time (PST). Remote (Americas only)."
See solution
Not viable, even with perfect English. Two lines decide it: "Remote (Americas only)" rules you out by geography, and "overlap 5 hours with US Pacific Time" from Spain (roughly a 9-hour difference from PST) would force you to work in the middle of the night. "Fully remote" doesn't mean "from any country": the fine print — the geographic filter and the time zone — overrides the headline.
Why this works: the benefits block is your filter, not theirs; time zone and geographic filters decide more rejections than English does, and it's better to catch this here than after three interviews.
Exercise: decode three job postings line by line
This is the work I actually want you to do, not just read about. Take three real job postings — from LinkedIn, Wellfound, We Work Remotely, or any company's careers page — and run them through this template. Write your answers; this exercise doesn't work in your head.
Decoding template (one per posting):
- Title and about the role: what verbs do they use? (own / drive / contribute / support). According to those, is the real seniority junior, mid, or senior? Does it match the title?
- Responsibilities: write, in one sentence, what your day-to-day would look like. Is there on-call? Is there mentoring? Anything you didn't expect?
- Requirements: underline the must-haves (lines with must, strong, solid, years of experience). Separately, mark the familiarity / exposure / nice to have ones. Count only the must-haves.
- Your honest match: of the must-haves, how many do you meet? Do you reach 60-70%? Yes / No.
- Benefits: is it actually remote for your country? Is the time zone compatible? Is the salary band visible?
- Generic, or a real problem behind it? one sentence justifying your answer.
- Decision: apply / apply while tailoring your resume / don't apply. And why.
What to expect from this exercise: the first posting will take you fifteen minutes and feel like work. The third will take you three and you'll read the seniority verbs almost without thinking. That shift — from decoding word by word to reading the posting like a map — is exactly the skill this lesson is building in you. It's not that your English got better in one afternoon: it's that you now know where to look.
Keep these three decodings. You'll reuse them in the module's project, when you build your target role brief: the postings you decoded are the real evidence of what the market is asking for the role you're aiming at.
What you're taking with you
- An English job posting has a fixed structure: about the role, responsibilities, requirements, nice to have, benefits, equal opportunity. Knowing the blocks makes it readable.
- The most honest block is responsibilities, not the title or the requirements list.
- Verbs encode seniority: own / drive / lead signal senior; contribute / support / help / learn signal mid or junior. The title lies; the verbs don't.
- In requirements, the language gives away the weight: must / strong / solid are core; familiarity / exposure / nice to have are optional. Count only the core.
- Applying with 60-70% of the must-haves is normal and expected. Self-rejecting for missing the nice to haves is the most expensive and most common mistake.
- A posting with a concrete, measured problem behind it is worth your time; one full of rockstar / wear many hats / fast-paced with no product or team named, read with low expectations.
Before moving on, you should be able to:
- Name the six blocks of a job description and say what each one is for without going back to the table.
- Look at an about the role line and say whether the main verb (own / drive / lead versus contribute / support / help / learn) signals senior, mid, or junior.
- Take a requirements list and separate the must-haves (must / strong / solid / years of experience) from the nice-to-haves (familiarity / exposure / nice to have), counting only the core.
- Decide in two or three minutes — apply, apply while tailoring your resume, or don't apply — and justify it with the 60-70% rule.
- Tell a generic posting (rockstar / wear many hats) apart from one with a real, measured problem.
If any of these still feels fuzzy, go back to the corresponding block before moving on: the next lesson builds on you already reading a posting like a map, not word by word.
In the next lesson we take the natural next step from here: when a posting says "B2 English required" or "C1 level," what does that actually mean on the job, and how does it compare to what you can do today? That's where we translate those labels into concrete abilities.
Resources
- Why Women Don't Apply for Jobs Unless They're 100% Qualified — Harvard Business Review — the source of the data point "men apply while meeting only 60% of the requirements": the evidence behind this lesson's 60-70% rule.
- We Work Remotely — Remote Programming Jobs — a board of remote job postings in English, ideal for pulling the three real job descriptions you'll decode with the template.
- Wellfound (formerly AngelList Talent) — startup postings, where "real problem" descriptions are most common and measured; a good contrast against generic filler.
- LinkedIn: how to turn on #OpenToWork — official guide to signaling to recruiters that you're job hunting; a practical complement once you already know how to read what postings are asking for.