ATS Resume Optimization: What Applicant Tracking Systems Actually Parse

Resume advice is unusually bad. It is written at enormous volume, it is mostly recycled, and a lot of it is aimed at a version of applicant tracking systems that does not exist.

This guide covers what these systems do mechanically, what that implies for how you build the document, and then the part that actually decides senior outcomes — what goes in the bullets.

What an ATS is, and what it is not

An applicant tracking system is the database and workflow layer a hiring team uses to manage candidates. Greenhouse, Lever, Ashby, and Workday are the ones you will meet most often in the U.S.

It stores applications, moves them through stages, holds interview feedback, and lets recruiters search the pool. It is infrastructure.

The widely repeated claim that these systems automatically reject most resumes does not describe how they are typically configured. Some can apply knockout rules — work authorisation, location, a required licence — but those act on answers you gave on the form, not on an assessment of your resume.

The realistic failure is quieter and worse. Your application submits. You get the confirmation. But the parse mangled your document, so when a recruiter searches the pool for the title or skill you actually have, you are not in the results. Nobody rejected you. Nobody formed a view. You were never retrieved.

The full mechanics are in what applicant tracking systems actually do with your resume. The short version: your file goes through text extraction, section detection, field mapping, and indexing — and each step can fail silently.

Format: what survives extraction

These are the changes with the highest return, in order.

Use a single column

The most common cause of scrambled text. A PDF stores positioned glyphs, not columns. Extraction generally walks content in a reading order that may run straight across your visual columns, interleaving a skills sidebar with your job history.

The output still contains every word. It no longer contains coherent statements. A recruiter reading the parsed text sees noise; a recruiter opening the original sees a nice design. Which one they see depends on the system.

Avoid tables for layout

Tables lose the relationship between cells during extraction. Where the table carried the meaning — this date range belongs to this employer — the meaning is what gets dropped. Use plain lines.

Keep contact details in the body

Some extractors treat page headers and footers as furniture and skip them. An email address that lives only in the header can produce a parsed record with no email address on it.

Use conventional section headings

Parsers detect sections by matching against expected labels. Experience, Work Experience, Professional Experience, Education, Skills are recognised. Where I've Made an Impact is not, and the section boundary may never be found.

Keep dates consistent and adjacent

Jan 2021 – Mar 2024 on the same line as the role. Consistent format throughout. Date parsing is how the system reconstructs your career timeline, and it is more fragile than you would expect.

Do not put text in images

A name in a logo, a skills chart, a rating graphic. None of it is text. None of it is extracted. None of it is searchable.

PDF or DOCX

Submit whatever the employer asks for. When both are offered, DOCX generally parses more predictably, because the document structure is explicit rather than inferred from glyph positions.

PDF is fine when it was generated from a clean single-column document by a normal word processor. PDF exported from a design tool, with text as outlines or in a complex layout, is where problems concentrate.

Never submit a scan or an image-based PDF. There is no text in it to extract.

Structure: the order that works

A conventional order, which is conventional because it survives parsing and matches what a reader expects:

1. Name and contact details — in the body, plain text.
2. A short positioning statement — three or four lines, not a paragraph of adjectives.
3. Experience — reverse chronological.
4. Education — brief, at the bottom, once you are past your first decade.
5. Skills — a plain list, not a grid of proficiency bars.

Skip the objective statement. Skip the photo — in the U.S. it introduces bias risk that many employers actively screen out. Skip references-available-on-request.

Content: the part that actually decides things

Once the document parses, the machine's role is over and everything depends on what a person reads. This is where senior resumes usually fail, and none of it is an ATS problem.

Write scope, not tasks

The most common weakness in a senior resume is that it describes activity rather than ownership.

Managed the engineering team and worked on platform initiatives.

This could be eight people or eighty, one product or a company. Compare:

Ran a 45-person platform organisation across four teams, owning developer infrastructure and CI for 300 engineers.

The second tells a reader where you operate. It also happens to contain the terms someone would search for, which is a side effect of being specific rather than a keyword strategy.

Anchor with numbers you can defend

Numbers work because they are checkable. Team size, budget, headcount supported, systems owned, revenue influenced, latency or cost moved.

The constraint is that you have to survive being asked about them. If you cannot spend ten minutes on how a number was measured and what you personally changed, do not put it on the page.

Lead with the outcome

Put the result first and the method second. Cut deploy time from 40 minutes to 6 by rebuilding the CI pipeline reads better than the reverse and survives being skimmed.

Include the hard parts

The details that distinguish a senior candidate are usually the ones people edit out: the constraint, the thing that went wrong, the decision made with incomplete information. A resume of unbroken success reads as either junior or unreflective. One line acknowledging a genuinely difficult call is worth several achievement bullets.

Problems specific to senior resumes

Length

Two pages. Three is defensible past twenty years or in academic and research contexts, but each additional page reduces the chance any of it is read.

The compression rule that works: recent roles get depth, older roles get a line. Your last two positions can take most of page one. Everything before that collapses into a short list of role, employer, and dates.

Twenty years of history

You do not need all of it. Roles from more than fifteen years ago can be a single grouped block with no detail. Nobody is evaluating you on what you did in 2007, and including it invites age inference without adding evidence.

For the same reason, graduation years past a certain distance are optional.

Manager or individual contributor

If you have moved between the two, the resume must state clearly which you are targeting now. A document that reads as equally weighted for both reads as uncommitted, and the reader will guess — usually wrong.

Overqualification

If you are targeting a role below your last title, the positioning statement has to address it directly. A reader who cannot construct a story for why a VP is applying for a director role will construct an unflattering one.

Tailoring, done properly

Tailoring means re-weighting genuine experience for a specific posting. It does not mean rewriting your history to match.

What is worth changing per application:

• The positioning statement. Three or four lines, aimed at this role.
• Bullet ordering within a role. Lead with what is most relevant here.
• Vocabulary. If the posting says "site reliability" and you wrote "infrastructure quality", align them — assuming they genuinely describe the same work.
• Which older roles get a line and which get detail.

What should never change: employers, titles, dates, or anything you would not repeat under questioning.

Doing this by hand for every application is tedious enough that most people stop after four or five. That tedium is the legitimate case for software, and it is covered in the AI job search guide.

Keywords, honestly

Keyword advice is where resume guidance goes furthest wrong.

The useful principle is narrow: recruiters search the pool, and a search matches text. If the employer's vocabulary and yours differ for the same thing, align them so you are retrievable.

That is the whole mechanism. It does not imply a density target, a match percentage, or a list of terms bolted onto the bottom of the page.

Things that do not work and can actively harm you:

• White text on a white background. Detectable, visible in the extracted text a recruiter reads, and read as dishonesty when found.
• A keyword block. Obvious, and it wastes the space where evidence should be.
• ATS score tools. They have no access to the employer's actual system. They score against a model they invented, and they will happily tell you a well-written resume is failing.
• Claiming skills you cannot discuss. The interview is twenty minutes away.

A worked example

Abstract advice about "showing scope" is easy to agree with and hard to apply. Here is the same role written three ways.

The version most people write:

• Responsible for the platform engineering team
• Worked on improving developer productivity and CI/CD
• Collaborated with cross-functional stakeholders to deliver key initiatives

Three bullets, no information. "Responsible for" tells a reader nothing about size or ownership. "Improving developer productivity" is a category, not an outcome. The third bullet is true of literally every senior role ever held and could be deleted with no loss.

The version that over-corrects:

• Drove transformational change across the entire engineering organisation, delivering world-class developer experience and best-in-class CI/CD capabilities that revolutionised velocity

One sentence, heavy adjectives, still no facts. This reads as someone compensating. It is also the register generated text tends to produce, which is a reason to be suspicious when a tool hands it to you.

The version that works:

• Ran a 45-person platform organisation across four teams, owning developer infrastructure, CI, and internal tooling for ~300 engineers
• Cut median CI time from 22 to 6 minutes by rebuilding the pipeline and introducing test sharding; adoption reached 90% of repos in two quarters
• Made the call to consolidate three competing internal deploy tools onto one, which cost us a quarter of migration work and was unpopular before it was obviously right

Note what the third bullet does. It describes a decision, a cost, and initial resistance. It is the least "impressive" line of the three and the most informative, because it is the one that could not have been written by someone who was not there.

Also note that the useful keywords — platform, developer infrastructure, CI, internal tooling — arrived as a consequence of being specific. Nobody had to think about keyword placement.

Gaps, changes, and the things people try to hide

Senior careers are rarely tidy. The instinct to obscure the untidy parts consistently backfires, because a reader who notices something being hidden fills the gap with something worse than the truth.

Employment gaps. State them briefly and move on. 2023–2024: career break (caregiving) or 2024: sabbatical is a complete answer. What draws attention is a suspicious jump in dates with no explanation, which invites the reader to invent one. Gaps are common enough now that they are unremarkable when stated plainly.

Short tenures. One short stint is noise. Three in a row is a pattern a reader will notice, so address it. A layoff, an acquisition, a company that folded — a four-word parenthetical does the job: (role eliminated in restructuring).

Moving down a level. If your last title was VP and you are targeting Director, the positioning statement has to say why, because otherwise the reader constructs a reason and it is usually "could not hold the bigger job". A single sentence — wanting to be closer to the work, a deliberate move to a larger company where the level maps differently — resolves it.

Contracting and consulting. Group it under one heading with the clients listed underneath, rather than presenting each engagement as a separate job. Six entries in three years reads as instability; one entry titled Independent consultant (2022–2025) with six clients underneath reads as a practice.

Career changes. Lead with what transfers. If you moved from consulting into an operating role, the relevant thing is not the change but the scope you now own. The old domain becomes context, not the headline.

Cover letters

Mostly optional, occasionally decisive, and almost never read at the length people write them.

Skip it entirely when the application is a form with no natural place for one. Write one when there is something a resume structurally cannot say: why this company specifically, why the apparent mismatch is not a mismatch, why you are moving now.

Three short paragraphs. Why this role and this company, in specifics that prove you read something. What you have done that maps to it, with one concrete example rather than a summary of your resume. What you want to do next and why it lines up.

The failure mode is the same as everywhere else: fluent, structurally identical, indistinguishable from every other letter in the pile. If your letter would work for a different company with three words changed, it is not doing anything for you.

A checklist

Format:

• Single column, no layout tables
• Contact details in the body, not the header
• Conventional section headings
• Consistent date format, on the same line as the role
• No text inside images
• Copy-paste test produces readable text
• Two pages
• Requested file format; DOCX when there is a choice

Content:

• Scope stated for every role — team size, org size, what you owned
• Numbers you can defend for ten minutes
• Outcome before method
• Recent roles deep, older roles collapsed
• Clear about manager or IC
• Positioning statement rewritten per application
• Employer's vocabulary where it genuinely matches your work

What to ignore

Resume templates with sidebars and skill bars. Percentage match scores from tools with no access to the employer's system. Advice to keep it to one page after fifteen years of experience. Any suggestion involving hidden text. Anyone confident about the exact proportion of resumes "rejected by ATS" — that number is repeated far more often than it is sourced.

Where PlaceMeFast fits

PlaceMeFast stores multiple resumes, tailors a version against a specific job description, drafts cover letters, and checks structure and keyword alignment for ATS parsing — so the mechanical work happens per application rather than getting abandoned after the fifth one.

It is not publicly available yet, and it covers U.S. searches only. It helps you produce a better-represented application; it does not promise interviews or offers, and nothing it generates should go out without you reading it.

Join the early-access list to hear when it opens.