How to write the perfect resume (2026 edition)

Most resume advice on the internet is at least ten years old, written for a job market that no longer exists. This guide is the 12-minute version of what we'd actually tell a friend who asked for help — a senior product manager, a backend engineer, a designer, a marketer. The principles transfer. The details are 2026-specific.

The 30-second rule

A recruiter spends six to thirty seconds on the first pass of your resume. Six seconds when they have 400 to triage. Thirty seconds when they have ten. Either way, your CV is competing with a short attention budget, not a long one. Everything that follows in this guide is downstream of that fact.

Three things have to be legible at a glance:

1. Your name and current role. Top of the page, biggest type on the document.
2. Where you've worked and what you've done there. Company names, role titles and dates in a single visual rhythm down the left margin.
3. Why you're worth a second pass. Two or three bullets per role that aren't list-of-responsibilities boilerplate.

If a recruiter can't get all three from a 5-second skim, the rest of your resume doesn't get read. Most resumes fail here — buried summary, ambiguous job titles, walls of undifferentiated bullets. Fix this first, then worry about polish.

Structure & length

One page until you have ten years of experience. Two pages from 10–20 years. Three only for senior executives where the second page is a public board / publications / patents list rather than ongoing responsibilities.

A working professional with eight years of experience and four jobs does not need two pages. They need to make ruthless choices about what belongs in the room. The argument for the second page is almost always "but I have more to say" — which is a writing problem, not a length problem.

The canonical section order, top to bottom:

1. Header (name, current role, location, email, phone, links)
2. Professional summary (2–4 sentences)
3. Experience (reverse chronological)
4. Education
5. Skills (grouped into 2–4 clusters)
6. Awards, publications, volunteering (only if substantive)

For senior individual contributors, swap Experience and Skills if the recruiter for your target role is screening for a specific tech stack. For academics and researchers, Publications often goes above Experience. Otherwise: don't get creative with section order. Recruiters and ATS systems are both pattern-matching on this exact shape.

The summary

Two to four sentences, prose, at the top. Done well, it's the most valuable real estate on your resume because it's the only place a recruiter is reading you, not parsing your history.

A good summary follows a simple shape:

[Seniority + functional area] with [N years] in [domain]. [One sentence on what you're known for, with one verifiable detail]. [Optional third sentence: a current focus area or capability the target role would care about].

Concrete example:

Senior product manager with 9 years in B2B SaaS. Built and led the pricing platform at Stripe through the launch of usage-based billing, owning the roadmap that took the product from $4M to $22M ARR in 18 months. Currently focused on activation-stage growth in developer-tools companies.

What this avoids: words like "results-driven", "passionate", "team player", "synergy", "rockstar", "ninja". Cut every one. They mean nothing because they could be true of anyone. Replace them with a sentence that could only be true of you.

Experience bullets

Three to six bullets per role. Three is fine. Six is the ceiling. If you have ten, you're listing responsibilities — pick the three that prove you can do the role you're applying to next, cut the rest.

Every bullet starts with an action verb in past tense (or present tense for your current role) and lands a result. The classic formula:

[Verb] [what you did] → [measurable outcome] / [scope or scale].

Compare these two bullets for the same work:

• Weak: "Responsible for product roadmap and stakeholder communication for the billing team."
• Strong: "Owned billing platform roadmap; 4 squads, 27 engineers. Shipped usage-based pricing in 11 weeks, lifting enterprise self-serve conversion 38% → 51%."

The strong version names the scope (4 squads, 27 engineers), the deliverable (usage-based pricing), the timeline (11 weeks), and the outcome with both before and after (38% → 51%). Every piece is verifiable on a phone screen.

Quantification — when to and when not to

Numbers make resumes credible. Made-up numbers destroy them on the first reference check. The rule: only quantify what you can defend in a one-hour conversation with a former manager.

Some things you can almost always quantify:

• Team size you led or coordinated with.
• Budget or ARR remit you owned.
• User count, transaction volume, or other product scale.
• Time-to-ship for the thing you're describing.
• Before / after of a specific metric you moved.

Some things people invent and then can't defend: dollar amounts that suspiciously end in three zeros, percentage lifts with no baseline, "saved $X million in costs" without a stated comparison. If you can't say compared to what, leave the number out.

Verbs to lead with

Vary them — the same verb three times in a row reads as lazy. A short cheat sheet by what you actually did:

• Built something: shipped, built, launched, designed, architected, prototyped, rolled out.
• Led people: led, managed, hired, mentored, coordinated, partnered, aligned.
• Drove a number: lifted, drove, grew, reduced, accelerated, increased, improved.
• Owned something: owned, set, defined, established, framed, prioritised.

Skip: "responsible for", "duties included", "was tasked with", "helped". They make you sound like a passive observer of work that happened to be in your name.

Skills section

Skills go below experience because they're the easiest section to skim and the recruiter is checking for keyword match, not narrative.

Group them into two to four clusters — never one endless wall of acronyms. A backend engineer might have:

• Languages: Go, Python, TypeScript, Rust.
• Frameworks: Echo, FastAPI, Next.js.
• Cloud / DevOps: AWS (EKS, RDS, S3), Terraform, Datadog.
• Practice: distributed systems, on-call leadership, mentoring.

A product manager's clusters look different — research methods, analytics tools, frameworks (Jobs-to-be-Done, OKRs), and so on. But the cluster shape is the same. It's faster to scan and it gives the ATS something structured to parse.

Resist the urge to list every technology you've ever touched. If you wouldn't survive a 10-minute technical question on it, leave it off.

Education

Three lines per degree: institution, degree + field, dates. Add a single line for thesis, GPA (if above 3.7), or honours only when the target role specifically values it.

Long after graduation, education compresses to a single line per degree at the bottom. Five-year-out professionals are not getting hired on their GPA.

Formatting rules

The non-negotiables:

• Single column. Two-column resumes fragment in at least four mainstream ATS vendors. We have a whole guide on why.
• One font for the whole document. Body and headings differ by weight and size, not typeface.
• No icons in the header. Many ATS parsers drop them or, worse, render them as garbage text.
• No tables. Tables are how ATS parsers fail most spectacularly — the reading order of cells often comes back interleaved.
• PDF over DOCX for the first read, unless the posting explicitly asks for DOCX. PDFs lock the layout. DOCX can re-flow depending on the recipient's Word version.
• Reasonable margins: 0.5"–0.75" all around. Margins smaller than that fail to print correctly and look frantic.

Tailoring to a job description

One generic resume is a 2010s strategy. Today's reality: every application benefits from at least light tailoring. Heavy tailoring for the roles you really want.

What to actually do when you tailor:

1. Read the JD twice. First for the top 3 must-haves. Second for the language they use.
2. Mirror the language on things that are already true about you. If the JD says "experimentation" and your bullet says "A/B testing", change it to "experimentation". You're not lying — you're matching vocabulary.
3. Reorder bullets in each role so the most JD-relevant ones appear first. You have one screen of attention per role; spend it on the thing that matches.
4. Promote a skill cluster. If the JD weighs SQL heavily, lift it out of "Other tools" into "Languages".
5. Update the summary. 30 seconds of editing. The summary should obviously, plainly, match the JD's stated role.

What not to do: invent experience to match the JD. Add a framework you don't actually know. Pad with keywords your resume doesn't support. Recruiters spot it. ATS systems weight it less than you think. Reference checks catch it.

Where AI helps (and where it doesn't)

AI is good at three resume tasks:

• Tightening language. Cutting fluff, sharpening verbs, removing duplicate ideas across bullets.
• Mirroring JD vocabulary. Mapping your existing facts to the keywords the JD uses.
• First drafts. Turning a list of "things I did" into structured bullets you can edit.

AI is dangerous at one thing: inventing facts. Companies, dates, metrics, technologies. A model that doesn't know it shouldn't invent will happily turn "led the billing team" into "led a team of 12 engineers across 4 timezones to ship $40M in incremental revenue" — none of which is verifiable. Reference checks catch this in the first round. Don't accept any AI suggestion you couldn't defend in a 15-minute phone screen.

We built WhiteResume around this exact constraint. Our system prompts explicitly forbid the model from inventing employers, dates, certifications, or metrics. The "Quantify" tool asks you for the numbers rather than making them up. The full breakdown is in our AI safety guide.

Before you ship

Three checks before you upload:

1. Run the ATS preview. See what the recipient's system actually extracts from your PDF. Names of companies and roles missing? Layout is fragmenting. (WhiteResume builds this in.)
2. Spell-check, then read aloud. Spell-check catches spelling. Reading aloud catches rhythm — "the for the the" survives a spell-check.
3. Send to one friend. Not for "feedback" — just to confirm the file opens, the fonts render, and the email looks like you wrote it. The cheapest QA possible.

Then submit. The hardest part of a job search is the volume — the 30th application looks indistinguishable from the 3rd unless you've built a process. This guide is the process.

Open WhiteResume if you want to write your next resume against this framework — the editor enforces single column, flags weak language, and lets you ship multiple variants from one master profile in a single sitting.