What an applicant tracking system actually does
The folklore says a robot scores your resume and bins it below a threshold. That is not how the software works. An applicant tracking system is a database with a search box: it stores applications, chops your resume into fields so a recruiter can filter on them, and shows them a list. The rejections are done by people, or by filters those people set, and the filters are usually blunt.
- Parsing is the part that genuinely breaks. Your resume is chopped into name, contact, employment history, education, and skills, and a layout it cannot follow produces a mangled record before a human sees anything.
- Search is the part that decides. A recruiter filters on a title, a location, a skill keyword, or a work authorisation answer, and reads what comes back.
- Knockout questions do auto-reject, and they are questions you answered in the form, not text on your resume. Work authorisation and years of experience are the usual two.
- There is no industry-standard score inside the system that decides your fate. Third-party checkers that quote you a percentage against a posting invented that number themselves.
The eight checks worth running
These are the mechanical ones, which means they are deterministic: the same resume always scores the same, so editing toward a pass is a real change rather than a reroll. None of them requires a model to judge, which is exactly why they can be trusted.
- Length. A resume with real content runs about 400 to 600 words per page. Under 260 reads as underwritten; over about 1,100 is a screener skimming rather than reading.
- Quantified bullets. At least 40% of your bullets should contain a number. A figure is what turns a claim into evidence.
- Outcome-first bullets. Anything starting with responsible for, worked on, helped, assisted, or involved in describes a duty rather than a result.
- Filler. Results-driven, team player, passionate about, detail-oriented, proven track record. Each one is a line a screener skips.
- Pronouns. A resume drops them: Led the migration, not I led the migration.
- Reachable. An email address in the body text, not in a header or footer where parsers routinely drop it.
- Parseable. No tables, no images, no text inside graphics. Each of those turns into a mangled field or nothing at all.
- Skill coverage. The skills you claim have to appear in the words on the page, because a keyword filter reads the text, not your intentions.
What actually breaks a resume in a parser
Almost every parsing failure is a layout decision that looked good in a document editor. The failure is silent, which is what makes it expensive: nothing tells you your last two jobs landed in the education field, and the recruiter never sees a record worth searching.
- Two-column layouts. Many parsers read straight across, interleaving your skills sidebar into your job descriptions line by line.
- Contact details in the page header or footer. A common parser drops both entirely, so your application arrives with no email on it.
- Tables, including invisible ones used for alignment. A row becomes one run-on line, or nothing.
- Text inside an image or a logo. It is not text, and no amount of it counts as a keyword.
- A PDF exported as a scan or built out of vector outlines, which is an image of a resume rather than a resume.
- Creative section headings. Where I Have Been is not recognised as Experience. Boring headings parse.
- Dates written in a format nobody else uses. Month Year to Month Year is the one that survives.
Keywords, without the keyword stuffing
Keywords matter for one narrow reason: a recruiter filtering a database on a term will not find a resume that does not contain it. That is a real effect and it is much smaller than the advice industry suggests. What it does not justify is a block of white text at the bottom of the page, which is the single fastest way to be dropped by the human who finds it.
- Use the employer's word for the thing, where you honestly have the thing. If the posting says PostgreSQL and your resume says relational databases, say PostgreSQL.
- Put the skill next to the work it was used for, not only in a list. A skills list nobody can attach to a job reads as decoration.
- Do not synonym-launder. One tool is not another because the posting asked for the second one, and the interview is where that gets found out.
- White text, hidden keywords, and keyword blocks in a footer are detectable and are treated as what they are.
Fixing it in the order that pays
The checks are not equally valuable. Two of them decide whether your resume exists as a searchable record at all, and the rest decide whether a human keeps reading. Do them in that order.
- First, anything that breaks parsing: columns, tables, images, headers. A resume that parses badly cannot be rescued by better bullets.
- Second, contact details as plain text near the top.
- Third, the bullets: outcome first, then a number wherever your work supports one.
- Fourth, the words the posting uses, where you honestly have the thing behind them.
- Last, length. Cut the oldest roles to a line each rather than trimming the recent ones, because length signals scope.