It's also mostly wrong — and the myth causes developers to make worse resumes, not better ones.

In this guide I'll cover what an ATS actually does with your resume, the small set of formatting rules that genuinely matter, how to mirror a job description without keyword stuffing, and a before/after example from a real software engineer resume. At the end there's a checklist you can run against your own resume in five minutes.

What an ATS actually does to your resume

An ATS (applicant tracking system) — Greenhouse, Lever, Workday, Ashby, iCIMS — is a database with a form on top. When you apply, it does three things:

1. Stores your resume file exactly as you uploaded it. A human can always open the original.

2. Parses it into structured fields: name, contact info, work history, education, skills.

3. Lets recruiters search and filter applicants by those fields and by keywords.

Notice what's missing: in most companies, the ATS does not auto-reject anyone based on resume content. Knockout questions ("Are you authorized to work in the US?") can auto-reject you. A recruiter spending six seconds skimming can reject you. But the widespread image of an algorithm scoring your resume and silently binning it below some threshold doesn't match how the mainstream systems are configured at the vast majority of companies.

So why does "ATS-friendly" still matter? Two reasons:

• Parsing failures are real. If the ATS can't extract your work history from a two-column layout or a text box, the recruiter sees a half-empty profile — and half-empty profiles get skipped.

• Search is real. Recruiters filter by keywords ("Kubernetes," "React," "staff engineer"). If the term isn't in your resume as literal text, you don't show up in the search.

ATS-friendly doesn't mean "beating a robot." It means parseable and searchable.

The formatting rules that actually matter

Good news: this list is short. You can ignore most of the folklore (no, an ATS doesn't reject you for using the "wrong" font).

Do

• Use a single-column layout. Multi-column resumes are the #1 cause of parsing errors — parsers read left to right and interleave your columns into word salad.

• Use standard section headings. "Experience," "Education," "Skills," "Projects." Parsers key on these. "Where I've Made an Impact" looks clever and parses as nothing.

• Use real text everywhere. No skills rendered as images, no headshot, no icon fonts for contact info. If you can't select it with your cursor in the PDF, the parser can't read it either.

• Submit a PDF exported from a text editor (Google Docs, Word, Typst, LaTeX, or a resume builder). Every mainstream ATS parses text-based PDFs fine in 2026.

• Put dates in a consistent, standard format. "Jan 2023 – Present" beats "23→now."

• Spell out acronyms once where it counts: "Amazon Web Services (AWS)" lets you match both search terms.

Don't

• Don't use Canva-style graphic templates for the version you upload. Beautiful, and they parse terribly — text boxes and vector layers turn into garbage. Keep a pretty version for handing out in person if you like.

• Don't put critical info in headers/footers. Some parsers skip them; your phone number shouldn't live there.

• Don't use tables for layout. Same interleaving problem as columns.

• Don't paste in invisible white-text keywords. Recruiters see the original file, parsers often normalize colors, and it reads as fraud when caught. It's the one trick that can actually get you blacklisted.

That's genuinely it for formatting. A boring single-column document with standard headings passes every parser I've tested. (We run resumes through the parsers behind the major ATS platforms as part of building JobScoutly's ATS resume checker — the failures are almost always columns, tables, and text-as-image, never fonts or colors.)

Keywords: how to mirror the job description without stuffing

Here's where developers overcorrect. Having learned that recruiters search by keyword, they dump 40 technologies into a skills section and call it done. That passes search filters and then fails the human in the loop, because a keyword wall signals "I have no idea what my actual strengths are."

The better mental model: the job description is the query; your resume is the document. Optimize for retrieval and relevance.

A process that works:

1. Extract the hard requirements. Read the posting and list the specific technologies, and seniority signals that appear in the requirements section — not the nice-to-haves buried in paragraph five. Usually it's 6–10 terms.

2. Map each one to evidence. For every requirement you genuinely have, make sure it appears in a bullet point attached to an outcome — not just in the skills list. "Cut p95 latency 40% by moving session storage to Redis" beats "Redis" in a skills pile, and it contains the keyword anyway.

3. Use the posting's exact vocabulary. If they say "React," write "React," not just "frontend frameworks." If they say "CI/CD," don't only write "GitHub Actions" — write "CI/CD pipelines (GitHub Actions)." Exact-match search is still how most recruiter filters work.

4. Let the misses go. If you don't have a hard requirement, don't sneak the keyword in anyway. Two matched requirements with strong evidence beat six weak mentions.

Doing this by hand for every application is tedious, which is why most people don't — and why tailored resumes stand out as much as they do. This is exactly the job we built the JobScoutly job match analyzer for: paste a job description, and it scores your resume against it, showing which required terms you're missing and which bullets carry your strongest evidence. Whether you use a tool or a highlighter, the point is the same — tailor per application, with evidence, in the posting's own words.

Before and after: a real software engineer bullet

Resume advice gets abstract fast, so here's the same experience written three ways.

Before (what most resumes look like):

• Responsible for backend development on the payments team using Node.js

• Worked on improving system performance and reliability

• Participated in code reviews and agile ceremonies

Parseable? Sure. Searchable? Barely — "Node.js" is the only keyword. Convincing? Not at all. There's no scope, no outcome, and "responsible for" describes a job posting, not a person.

After (parseable, searchable, and evidenced):

• Built and maintained payment-processing services in Node.js/TypeScript handling ~2M transactions/day on the payments team (4 engineers)

• Reduced checkout p95 latency from 1.8s to 700ms by profiling PostgreSQL query plans and introducing Redis caching for pricing lookups

• Cut deploy failures ~60% by adding canary releases to the CI/CD pipeline (GitHub Actions, Kubernetes)

Same job. But now a recruiter searching for TypeScript, Postgres, Redis, Kubernetes, or CI/CD finds this candidate, and the human who opens the profile sees scale, numbers, and specific technical decisions. Every keyword is load-bearing.

The pattern for each bullet: verb + what you built/changed + measurable outcome + the technologies as they naturally appear. If you can't remember exact numbers, honest approximations ("~2M/day," "roughly 60%") are standard and fine.

The 5-minute ATS checklist

Run your current resume through this before your next application:

• [ ] Single column, no tables, no text boxes

• [ ] Standard headings: Experience / Education / Skills / Projects

• [ ] All text is selectable in the final PDF (try it — Ctrl/Cmd-A)

• [ ] Contact info in the body, not the header/footer

• [ ] Consistent date format, month + year

• [ ] 6–10 keywords from the target job description, each backed by an evidence bullet

• [ ] Exact vocabulary from the posting (their "React" is your "React")

• [ ] Zero requirements you don't actually meet keyword-snuck in

• [ ] Acronyms spelled out once (AWS, CI/CD, ATS itself if relevant)

• [ ] One page (under ~10 years experience) or two pages max

If you want the formatting handled for you, JobScoutly's free resume builder outputs single-column, parser-tested PDFs by default — you focus on the evidence, it handles the structure.

TL;DR

The ATS isn't rejecting you; unparseable formatting and unsearchable content are. Use a boring single-column layout with standard headings, write bullets that pair the job posting's exact keywords with measurable outcomes, tailor per application, and skip every trick that involves hiding text. That's the whole game — the rest of the interview pipeline is about what you actually built.

Built by the team behind JobScoutly, a free resume builder and job match analyzer. All guides are free — no signup required to read them.