In this chapter
We'll learn to decode job descriptions — the parts of an advert, must-haves versus nice-to-haves, what "3+ years" and long technology lists really mean, how to map requirements to what you already know, and the warning signs — explained as reading a recipe where some ingredients are optional.
The Problem in Real Life
John puts three adverts on the screen. The first one asks for: "Backend Engineer — Node.js, TypeScript, PostgreSQL, Redis, Docker, Kubernetes, AWS, Kafka, GraphQL, CI/CD, 3+ years." Anna's heart sinks. "I don't know Kubernetes properly. Or Kafka. Or GraphQL. And I have one year."
"Read it again," John says, "like an engineer this time, not like someone being judged." He opens a blank document and splits it into two columns: Must and Nice.
A job advert is a wish list, not an exam.
John
"I Don't Meet Every Requirement" vs. Reading What They Really Need
Endless technology lists
Adverts list every tool the team has ever touched, mixed with what really matters.
Years of experience
"3+ years" stops many people who could do the job well.
Warning signs
Some adverts reveal problems — if you know how to read them.
Understanding Job Descriptions and Technical Requirements
The recipe analogy: a recipe lists ingredients, but they're not all equal. Flour, eggs and butter are essential — no cake without them. The vanilla, the nuts and the sprinkles on top are nice, but a good baker makes a fine cake without them and adds them later. Job descriptions mix essential ingredients with sprinkles; your job is to tell them apart.
- The parts of an advert: the title and level (junior, mid, senior — Act 01); about the company and team; responsibilities (what you'd actually do — the most honest part); requirements or "must have"; nice to have or "bonus"; benefits, location and salary; and how to apply.
- Read the responsibilities first: "Build and maintain APIs, write tests, take part in code review and on-call" tells you more about the job than the technology list. Ask: could I do this work, with some help, in my first months?
- Must-haves vs. nice-to-haves: essentials are usually the language, the type of work (APIs, databases), and fundamentals (Git, testing, HTTP, SQL). Long lists of tools are usually the team's whole stack — few people know all of it when they join. If something appears in the title or the first lines, it's probably essential; if it's at the end of a long list, probably not.
- Years of experience: "3+ years" is a rough way of saying "can work independently on normal tasks". A strong foundation, real projects and good habits can make up for some of it, especially for junior and mid-level roles. Apply when you meet most of the essentials — many people suggest about 60–70% — rather than waiting for 100%.
- Mapping requirements to what you know: turn the advert into your own table: each requirement, how well you know it (have used it at work / built a project with it / understand the concept / new), and evidence (a project, a course, a task). This becomes your application and interview preparation.
- Warning signs: a junior role demanding ten years in a technology that's eight years old; "must work under pressure, weekends as needed" with no mention of on-call pay; no mention of mentoring for a junior role; very vague responsibilities; a "rockstar ninja" who will do frontend, backend, DevOps, design and sales.
| Requirement | Must or nice? | Anna's level | Evidence |
|---|---|---|---|
| Node.js + TypeScript | Must | Used at work daily | BlueTicket features, Hack Day |
| PostgreSQL | Must | Used at work | Acts 13, 25; organiser dashboard |
| REST APIs | Must | Used at work | Act 23 payment flow, waitlist API |
| Docker + CI/CD | Must | Built a project with it | Event Waitlist pipeline |
| Testing | Must | Used at work | Act 17 timezone test, waitlist tests |
| Redis | Nice | Understand the concept | Act 14 caching; Sale Day |
| Kubernetes | Nice | Understand the concept | Act 21 mental model |
| Kafka | Nice | Understand the concept (queues) | Acts 14, 21 |
| GraphQL | Nice | New | — |
| The advert says | It usually means |
|---|---|
| 3+ years of experience | Can work independently on normal tasks |
| Familiarity with X | Have used or understood it; not expert |
| Strong communication skills | Clear PRs, tickets and questions (Act 24) |
| Ownership | You build it, you run it (Act 21) |
| Fast-paced environment | Could mean exciting — or chaotic; ask in the interview |
Anna's two columns for the first advert: Must — Node.js and TypeScript (daily work), PostgreSQL (Act 13, plus the organiser dashboard), APIs (Act 23), Docker and CI/CD (Acts 19, 21, Hack Day), testing (Act 17). Nice — Kubernetes (she knows the model from Act 21), Kafka (a queue, Act 14 — she knows the idea), GraphQL (new), AWS (she knows the building blocks from Act 20). Years: one, but with a production incident, a deployed project and a live feature behind her. "I match all the musts," she says, surprised. "And I understand most of the nice ones."
Key Takeaway
Read job adverts like a recipe with optional ingredients: read the responsibilities first, separate must-haves (language, kind of work, fundamentals) from nice-to-haves (the team's long tool list), treat years of experience as a rough signal of independence, and apply when you meet most essentials. Map each requirement to your evidence — it's your application and interview prep — and watch for warning signs like impossible demands or no mentoring for juniors.
Why This Matters
Many capable beginners never apply because they read adverts as exams. Knowing how to separate essentials from wish lists, map requirements to your own evidence and spot warning signs means you apply to the right jobs, with confidence — and arrive at interviews already knowing what to talk about.
The gaps are clear now: Kubernetes in practice, Kafka, GraphQL, AWS details, and deeper database skills. John hands her a calendar. "Turn that into a plan — one year, not one weekend."