Stop writing a job description. Write your resume.

01The core misconception

"More keywords = more shortlists." That's only half true.

Yes, ATS scoring rewards relevant keywords. But there's a second reader after the ATS: a human. And the fastest way to lose that human is to hand them a resume that reads like the job posting they wrote, instead of a record of what you built.

A recruiter should feel like they're reading a case study of your work — not a checklist you copied.

02How ATS actually reads your resume

Before a human ever opens it, software does.

An Applicant Tracking System parses your resume file into structured fields — name, contact info, work history, education, skills — before a recruiter ever sees it. Section 01 made the readability case against keyword-stuffing; this is the parseability case for why formatting choices matter just as much as wording.

03Three things to fix first

Before you touch a template.

04The bullet-writing formula

Every strong bullet is three things, stitched together.

Principle 02 says every bullet needs a "so what." That's the right instinct without a repeatable shape — so use this one:

Applied: Cut new-engineer ramp-up time (X) from 3 weeks to 1 week (Y) by writing an internal onboarding wiki and automating dev-environment setup (Z).

Verbs that carry weight, and phrases that don't

05"I don't have a project to show"

Turn a small fix into a resume-worthy project.

You don't need a greenfield build to have a project. You need a bug fix, an enhancement, or even a small script, plus the discipline to document it like it mattered. Here's the path, using AI at every step.

06Build the architecture mental model

You can write the bullet. Can you defend it?

Here's the trap: you fix one bug in one service, write a clean resume bullet about it, and walk into the interview ready to talk about that one function. Then the interviewer asks something like "where does this request originate, what's the latency budget end to end, and what happens if that downstream service is down?" — and you've never looked past the file you touched.

Almost every real bug fix sits inside a system much bigger than the file you edited. You don't need to have built every service around it — you do need to understand how the whole thing fits together well enough to explain it out loud.

A concrete example

Say you fixed a stale-cache bug in a pricing-service — one function, maybe ten lines. That function still sits inside a flow that looks something like this:

"I fixed a caching bug" is a fine opening line. What separates candidates is being able to keep going: where the request actually comes from, which calls are synchronous versus async, where most of the latency lives, how many replicas each service runs, and what happens on a pod crash or a downstream timeout — even for the services you never touched.

Let AI build the map for you

This is exactly the kind of research AI is good at, given the right inputs: the actual code around your change, and any existing internal documentation — design docs, wikis, READMEs, architecture decision records. Point it at both, and ask for an in-depth, conference-talk-style architecture write-up covering the whole system around your change, not just the file you touched.

That last instruction matters twice over: naming the concepts (not just the services) is what makes the difference between "we use Redis" and "we use Redis as a write-through cache with a 5-minute TTL to protect the pricing DB from read amplification" — the second is the sentence that survives a follow-up question. And asking for the output as a single HTML page, the same way every guide on this site is one, turns a wall of chat responses into something you can actually navigate, bookmark, and re-read the night before an interview.

07Quantify everything

If it's not measured, it didn't happen.

Recruiters skim. A number stops the skim. Even a clearly reasoned estimate beats a vague adjective every time.

08Section order by career stage

Lead with your strongest evidence, not a fixed template.

Both sample resumes at the end of this guide use the same section names, but not the same order — that's deliberate. A resume should open with whatever most directly proves you can do the job, and that answer changes with experience.

09Red flags that get resumes rejected

None of these disqualify on their own — together, they add up fast.

• ✕
  Unexplained employment gapsA gap rarely disqualifies by itself — an unexplained one paired with thin content around it invites the worst assumption.
• ✕
  Inconsistent verb tenseMixing past and present within the same role reads as careless, even when the work itself wasn't.
• ✕
  A generic objective or summary statement"Hardworking team player seeking growth opportunities" says nothing a real bullet couldn't say better.
• ✕
  No GitHub, LinkedIn, or portfolio linkFor technical roles, an easy way to verify your work is expected, not optional.
• ✕
  Length mismatch for your experienceOne page under roughly 5 years; two pages beyond that — never a lonely half-page third sheet.
• ✕
  An unprofessional email handleA five-minute fix with a disproportionate first impression.
• ✕
  Technology you can't defend for 5 minutesTies directly to section 06 — if it's on the resume, it's fair game in the interview.
• ✕
  Soft skills with no proof"Excellent communicator" is an adjective. "Presented migration risk to 3 VPs and got sign-off in one meeting" is evidence.

10The final pass

Before you hit export.

• ✓
  No bullet reads like the job postingRead each line and ask: could this sentence appear unchanged in the JD? If yes, rewrite it as something you did.
• ✓
  Every project bullet has a numberTime, cost, scale, error rate, or percentage — pick the one that's true and defensible.
• ✓
  Every technology listed is one you can talk about for 5 minutesDon't list a tool you touched once. Interviewers will ask, and it will show.
• ✓
  You've used AI to cross-question yourselfRun each project through an AI-generated mock interview before a human does it for real.
• ✓
  Time spent on the resume ≈ time spent applyingA hundred applications with a weak resume converts worse than twenty with a strong one. Fix the resume first.

11FAQ

The questions that come up every time.

Next steps

See a filled-in example, watch the walkthrough, or get a second pair of eyes.

Sample resumes — the guide, applied

Two fictional but realistic resumes built from the advice above — one for a college graduate with no full-time experience, one for an engineer a few years in with multiple employers. Every bold number below is quantified the way section 05 argues for: a real percentage or figure, never just a direction.

Every quantified line above traces back to the before → after examples in section 05 — worth reading side by side with your own draft, whichever sample is closer to where you are.