Most large employers screen applications through an applicant tracking system, and almost nobody applying has seen one from the inside. The advice that fills the gap is mostly folklore — some of it useful, a lot of it invented, and a surprising amount of it selling something.
Here is the honest version. An ATS does three things with your resume: it parses the file into structured fields, it indexes the text so it can be searched, and it presents the result to a human who filters and reads. Only the first step is really about your document, and it is the one you have the most control over.
Step one: parsing
A parser reads your file and tries to work out which run of text is a job title, which is an employer, which is a date range, and which is a bullet describing what you did. It is not reading for meaning. It is looking for structure — headings that look like headings, dates that look like dates, and one sensible order to read the page in.
This is where document choices matter, because a parser can only work with what your formatting actually says. Visual hierarchy that exists only in the eye of a human reader is not hierarchy to a parser.
| Parses cleanly | Can go wrong |
|---|---|
| A single column, read top to bottom | Two columns, which can interleave into one stream |
| Real heading styles | A “heading” that is just bold text a point larger |
| Dates in a consistent format | Mixed formats — 2023, Mar '23, and 03/2023 in one document |
| Body text in the document flow | Text inside a floating text box or a graphic |
None of this is a rule that every system enforces the same way. It is a description of what makes a document easy or hard to read mechanically, and easy is strictly better than hard when you do not know which system is on the other side.
Step two: indexing and search
Once your resume is parsed, the text is indexed so recruiters can search it. This is the part people mean when they say “keywords”, and it is less mystical than it sounds: a recruiter filtering for Kubernetes is running a search, and a resume that only ever says “container orchestration” does not match that search.
That is not an argument for stuffing your resume with terms. It is an argument for using the posting's own words where you genuinely have the experience. If the job says Kubernetes and you have run Kubernetes, the word should appear. If it says Kubernetes and you have not, no amount of keyword strategy fixes that, and claiming it is how you fail an interview instead of a filter.
Why the same resume performs differently across jobs
Two postings for what looks like the same role can use entirely different vocabulary for it — one asks for “data pipelines”, the other for “ETL”. A single fixed resume matches one and misses the other, having described identical work both times. That mismatch is the actual problem tailoring solves, and it is why the fix is per-application rather than one better master copy.
Step three: what a human sees
After parsing and indexing, a person opens a list. Depending on the system and how the employer has set it up, they may see your parsed fields, a preview of your original file, or both — and they will skim before they read.
This is worth sitting with, because it cuts against the most common piece of ATS advice. Stripping a resume down to plain unformatted text to “be safe” optimises for a machine that has already done its job by this point, and hands a worse document to the person who makes the decision. The goal is a document that parses cleanly and reads well, not one traded off against the other.
What you actually control
- Give the parser clean structure — one column, real headings, consistent dates, no text trapped in graphics.
- Use the posting's own vocabulary for the work you have genuinely done, rather than a synonym you happen to prefer.
- Lead each bullet with what you did and what changed, so the human skimming it gets the point in one line.
- Send the file format the employer asked for, and keep your formatting intact when you tailor it.
What nobody can promise you
No tool can guarantee how a particular employer's system will parse or score your resume, because that configuration is private and varies by company. Anyone who tells you otherwise is describing a product they cannot have tested against.
What is achievable is narrower and more useful: a document that is structurally easy to parse, that uses the language of the job you are applying to, and that reads well to the person who opens it. That is the whole job.
It is also, precisely, what Rezifi does to a resume you already have — it reads the posting, rewrites your bullets against it, and leaves your formatting untouched, so the document a recruiter opens is still yours.