Engineering screeners — human and parser alike — match stack terms literally. If the posting says Go, Kubernetes and PostgreSQL, those exact words need to appear; "golang" usually still matches but "container orchestration" does not match "Kubernetes." Keep a compact skills section grouped by kind (languages / infrastructure / practices), and make sure every skill you'd defend in an interview also appears inside an experience bullet doing real work — "Cut p99 latency (Go, Redis)" is worth ten entries in a skills list.

Resist the 30-item skill dump. Senior engineers reviewing resumes read a long undifferentiated list as junior signal — it says you can't tell your core stack from things you touched once. Twelve to fifteen skills you'd happily whiteboard about beats an alphabet of frameworks.

The strongest engineering bullets pin the work to a system-level number: latency (840ms to 210ms p99), scale (2M orders/month, 30K requests/day), reliability (MTTD from 22 to 6 minutes), or money ($96K/year in licensing, $18K/quarter in refunds). "Improved performance of the checkout service" is unfalsifiable; "cut p99 checkout latency 75% on a 2M-order/month path" invites exactly the follow-up questions you want in an interview.

The parenthetical-stack pattern — result first, tools in parentheses — solves the keyword problem without stuffing: "eliminated duplicate-charge incidents (idempotency keys, Postgres advisory locks)." The reader gets the outcome, the parser gets the nouns, and the bullet stays one line.

If you have under ~3 years of experience, a projects section is your experience section's peer, not an appendix. The bar: each project should be linkable (GitHub repo or live URL), state its stack, and carry one number — stars, users, requests/day, dataset size. Two maintained projects with real usage beat eight tutorial clones; hiring engineers click the links, and a repo with a README, tests and recent commits is the most verifiable claim on the whole document.

Engineers distrust template mills for a concrete reason: those sites optimize for visual novelty — two-column layouts, icons, skill bars — which both parses worse and signals to engineering reviewers that you optimized the wrong thing. Jake's format won the community for the opposite reasons: dense, single-column, content-first, and born as an open LaTeX file engineers could read and modify. That's why this page reproduces the format exactly — the original's typeface included — instead of a lookalike built in a page editor.