How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It

A developer offers guidance on crafting a developer CV that satisfies both applicant tracking systems (ATS) and human recruiters. The advice includes using standard section headers, avoiding complex layouts, matching job posting language, and quantifying achievements to appeal to human readers.

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It Most developer CV advice picks a side: optimize hard for the applicant tracking system, or write something a human will actually enjoy reading. You need both, because both readers are real — a bot filters you before a human ever sees the file, and then a human decides whether to actually call you. What the ATS is actually doing It's not "AI" in any sophisticated sense most of the time — it's parsing your document into fields name, contact, work history, skills and keyword-matching against the job description. That means: - Stick to standard section headers — "Professional Experience," "Education," "Skills." Creative renaming "My Journey," "What I Bring" can break the parser's assumptions. - Avoid tables, text boxes, and multi-column layouts for anything containing content the ATS needs to extract — many parsers read left-to-right, top-to-bottom, and a two-column layout can scramble your work history into nonsense. - Match the language of the job posting, not just your own vocabulary. If they say "Node.js" and you only wrote "backend JavaScript," you may not match the keyword filter even though you clearly qualify. - Save as .docx or a text-based PDF , not an image-based or heavily designed PDF — if you can't select and copy the text yourself, the parser probably can't either. What makes a human actually want to talk to you Once you're through the filter, the CV needs to do a different job: convince someone you're worth 30 minutes of their day. - Quantify impact where you can — "reduced page load time by 40%" beats "improved performance." If you don't have a number, describe the before/after concretely instead. - Lead each bullet with what changed, not what you were assigned. "Migrated the checkout flow to a queued job to eliminate timeout errors" tells a much richer story than "responsible for checkout flow." - Cut anything that isn't verifiable or specific. Soft-skill bullet lists "great communicator," "team player" do almost no work on their own — show it through what you accomplished with other people instead. - Keep total length proportional to experience. Early-career: one page. Deep into your career: two pages, tightly edited, not a full chronological diary. The trap: over-optimizing for one reader at the expense of the other A CV stuffed with every possible keyword reads like noise to a human reviewer. A CV written purely for narrative flow with no matching language can get filtered before anyone reads it. The fix isn't a clever trick — it's writing the accurate version of your experience using the same words the industry and this specific job posting uses to describe that work. One thing worth doing before every application Read the job posting slowly and underline the specific technologies and responsibilities they named. Then check your CV against that list — not to fabricate experience you don't have, but to make sure the real experience you do have is described using their words, not just yours. That single pass fixes more rejections than any template swap.