Two readers,
one page.

A resume is optimized for the wrong audience by almost everyone, because they forget the first reader is a machine. Most companies run applications through an ATS (applicant tracking system) that parses your resume and often scores how well it matches the job description — especially the required skills. Score below the bar and you can be filtered out or ranked so low no human ever reaches you. The uncomfortable truth is that a perfectly qualified engineer can be auto-rejected because their resume didn't contain the specific words the ATS was scanning for.

So a resume has two jobs, in order. First, clear the machine: contain the keywords from the job description (for skills you genuinely have), in a format the parser can read. Second, win the human: once a recruiter or hiring manager is actually reading, convince them fast with concrete, quantified evidence of impact. These are different optimizations — the machine wants coverage, the human wants credibility — and both, conveniently, respond to measurable things. Optimize for only the human and you may never get read; optimize for only the machine and you'll get read and forgotten. This handbook is both, in sequence.

The ATS gate is fundamentally a coverage check: of the skills and keywords the job requires, what fraction appear on your resume? Below a threshold, you're filtered. So the move is to tailor per job — read the posting, pull out the required technologies and skills, and make sure the ones you actually have appear using the job's own wording. If it says "Kubernetes," write "Kubernetes," not just "container orchestration"; the parser matches terms, and a synonym it doesn't recognize is a miss.

Two rules keep you on the right side of it. Format for parseability: use a clean, standard, single-column layout, because tables, text boxes, images, multi-column designs, and header/footer text routinely confuse ATS parsers and can drop your content entirely — submit a normal PDF or docx, not a design showpiece. And be honest: the goal is genuine coverage of the requirements you meet, phrased in the posting's vocabulary — not keyword-stuffing or claiming skills you lack, which fails the moment a human or an interview tests it. Clearing the ATS is necessary but not sufficient; it only earns you the chance to be read. Think of it as a spam filter for job applications: get flagged and your qualifications are irrelevant, so the small, mechanical work of matching keywords and using a clean format has enormous leverage — it's the difference between being evaluated and being invisible.

Once a person is reading, everything changes: they're skimming dozens of resumes in seconds, looking for signal that you get results. The single biggest lever is quantified impact — bullets with a number.

Numbers make an accomplishment concrete, credible, and memorable, and they signal that you think in outcomes rather than tasks — which is exactly what distinguishes a strong engineer from a busy one. "Reduced latency 40%" lands; "worked on performance" evaporates. Not every bullet can carry a metric, but the share of your bullets that show a number is a good proxy for how strong the resume reads. The weakest and most common style is the responsibility bullet ("responsible for X") — it describes what you were assigned, not what you achieved, and reviewers discount it because everyone can claim to be "responsible for" things. Rewrite responsibilities as accomplishments with results, lead with the strongest, and you convert a skim into interest. The machine wanted the right words; the human wants proof, and a number is the cheapest proof there is.

The ATS score is keyword coverage — matched over required — and the gate passes above a threshold:

Resume {python, react, docker, aws} vs required [python, react, kubernetes, aws] → 3/4 = 0.75; passes a 0.7 bar, fails a 0.8 bar. The miss is "kubernetes".

For the human, a bullet's strength tracks whether it carries a measurable result — a number:

Quantified-impact bullets are the ones a reviewer remembers. The runnable version below computes ATS coverage, the missing keywords, the gate, and picks out the strong bullets.

For engineers, the resume is a claim and the portfolio is the evidence — proof you can actually build things. Its whole job is to reduce the reviewer's uncertainty about whether you can do the work, fast, so the guiding principle is quality and clarity over quantity:

The reviewer is busy and skeptical, so make the strongest evidence obvious and easy to reach — pin the best repos, lead the README with a screenshot or demo link, and don't bury a great project behind ten abandoned ones. A common mistake is treating the portfolio as a completeness exercise ("here is everything I've ever touched"), when it's really a curation exercise ("here is the best proof that I can build what you need"). One deployed, well-documented project that solves a real problem does more than a dozen tutorials-followed-along. The resume gets you looked at; the portfolio closes the gap between "claims skills" and "has demonstrably used them" — which, for an engineer, is often what tips a maybe into an interview.

The first is the one-resume-for-every-job approach. A generic resume matches no specific posting's keywords well, so it scores poorly on every ATS and reads as un-tailored to every human — tailoring the keywords and the top bullets per role is tedious but is exactly the mechanical work that gets you past the filter. The second is the design-heavy resume that won't parse: the beautiful multi-column template with icons and a sidebar often gets mangled by the ATS, dropping half your content — a clean single-column layout that looks plainer wins more interviews than a gorgeous one the machine can't read.

Two more. Responsibility bullets with no results: "responsible for X" is the default and the weakest form, because it describes a role, not an achievement — rewrite as action + quantified outcome, and lead with your strongest. And a portfolio that's a graveyard: a GitHub full of half-finished forks and empty repos actively hurts, because it signals unfinished work — curate down to a few things that actually work and are clearly documented. The meta-lesson is that a job search is an optimization against two measurable readers: clear the ATS with honest keyword coverage in a parseable format, then win the human with quantified impact and curated proof. Both are learnable, mechanical skills, not mysteries — and doing the small, unglamorous work of tailoring keywords and adding numbers to bullets moves more needles than almost anything else in a job hunt, because it's the difference between being filtered out and being interviewed.