How ATS and Hiring AI Algorithms Work (Why 75% of Resumes Are Rejected)

An ATS is enterprise software that automates hiring workflows. The systems you are most likely being screened by are Workday, Greenhouse, Lever, Taleo and SAP SuccessFactors.

Their job is arithmetic. When one opening attracts 1,000 applications, no recruiter can read 1,000 resumes. The ATS parses, scores and ranks every submission, then surfaces roughly the top 15 to 20 candidates. Everything below that line is archived without review.

A. Parsing

The system first strips raw characters out of your file. Parsing breaks when the document contains:

• Two-column layouts or invisible tables — a phone number in the left column fuses with a company name from the right.
• Section headings rendered as images or icons instead of selectable text.
• Decorative symbols, progress bars and vector drawings.

B. Timeline Reconstruction

The parser reads employment dates (January 2021 – March 2023) to compute total years of experience. Inconsistent date formats or scrambled ordering make the system calculate your tenure as zero — and seniority filters then drop you automatically.

C. Keyword and Role Matching

If the posting mentions "PostgreSQL" and "microservice architecture", the ATS checks whether those exact terms appear in your skills or experience sections. The higher the overlap, the higher you rank.

1. Single-column hierarchy. Avoid the two-column, chart-heavy templates that look impressive on screen. A plain top-to-bottom structure is what parsers read most reliably.
2. Conventional section headings. Write "Work Experience", not "What I've Been Up To". Creative headings prevent the parser from mapping your content to the right field.
3. Standard fonts. Stick to fonts every system resolves correctly: Arial, Calibri, Cambria, Georgia, Helvetica, Times New Roman, Inter, Lato or Open Sans.
4. Bullets containing numbers. Percentages, budgets, headcounts and time savings give ranking algorithms something concrete to score.

Resuzu Analyzer reproduces how modern parsers actually behave, running 36 deterministic rules over your file:

• 8 mechanical checks — scannability, column layout, font family and size, embedded graphics, contact placement, page density, file name.
• 18 content and structure rules covering sections, dates, personal data, skill grouping and section ordering.
• 5 Action-Scale-Outcome (ASO) checks that measure the depth of your experience bullets.

The same resume always produces the same score — the engine is deterministic, so you can fix one issue at a time and watch the number move.

Vendors describe their products as AI-powered, and the phrase covers three very different things. Knowing which one you are facing changes what you should optimise for.

Deterministic parsing. Extracting characters, coordinates, fonts and link annotations from a file. No model is involved; it is engineering, and it either succeeds or produces garbage. This layer decides whether you exist in the database at all.

Statistical matching. Comparing the vocabulary of your document against the vocabulary of the posting. Older systems do literal keyword matching; newer ones use embeddings, so "Postgres" and "PostgreSQL" register as related, and "led a team of eight" registers as evidence of management. Embeddings are more forgiving of synonyms, but they still cannot infer a skill you never mentioned.

Ranked shortlisting. Combining match score with filters — years of experience, location, work authorisation, salary expectation — into an ordered list. A recruiter opens that list from the top.

The practical consequence is a strict ordering of effort. No amount of keyword optimisation rescues a document that failed to parse. Fix the mechanics first; tailor the vocabulary second.

"White text keywords trick the system." They do not. Parsers extract characters regardless of colour, so the hidden block lands in the same text the recruiter can read in the parsed preview. When it is found — and it is routinely found — the application is discarded and, at larger employers, flagged.

"PDFs are always rejected; send a Word file." This was true of some systems a decade ago. Today the major platforms handle both. What matters is the internal structure, not the extension: a single-column PDF with a real text layer parses more reliably than a DOCX built out of invisible tables.

"The ATS rejects you automatically if you score below a threshold." Most systems do not auto-reject on score; they rank. The effect is the same — nobody reads position 340 — but the mechanism matters, because it means there is no magic number to clear, only a position to improve.

"Applying to more jobs improves the odds." Volume without tailoring lowers your average match score across every application. Ten targeted applications reliably outperform a hundred generic ones.

You do not have to guess how a system sees your document. Two checks take under five minutes.

The first is manual: open your PDF, select all, paste into a plain text editor. The order and content of that paste is close to what a parser extracts. If your job titles appear interleaved with your skills list, you have a column problem.

The second is the analyzer. Resuzu reproduces the parsing layer with real coordinate and font data, then reports what broke and where — including an overlay that marks the exact position of each finding on your document. Because the engine is deterministic, the number moves only when the document changes, which makes it usable as a feedback loop rather than a verdict.

The screening you face is not uniform, and tailoring your effort to the likely pipeline is worth more than a generic optimisation pass.

Large enterprises (1,000+ employees). Almost certainly Workday, Taleo or SuccessFactors, almost certainly with a portal that re-parses your PDF into structured fields you then have to correct by hand. That correction screen is a gift: it shows you exactly what the parser extracted. If the fields come back scrambled, your document has a mechanical problem that will also affect every other application you send.

Mid-size companies (100–1,000). Usually Greenhouse or Lever. Parsing is generally better, screening is a mix of automated filtering and a recruiter skimming, and keyword overlap matters more than raw mechanics — though mechanics still decide whether your text exists.

Small companies and startups (under 100). Often a shared inbox or a lightweight tool. A human very likely opens your file. Mechanics still matter, because a broken PDF looks careless, but the reading is human and the summary paragraph carries more weight than anywhere else.

Agencies and recruiters. They maintain their own databases and search them months later. This is the one case where broad, accurate keyword coverage genuinely pays: you want to be findable for a role that does not exist yet.

Section 2B mentioned that the parser reconstructs your employment timeline. That reconstruction is worth understanding in detail, because it fails silently and the consequences are large.

Seniority filters are among the first applied, and they run on computed years of experience, not on what your summary claims. If the parser cannot read your dates, computed experience is zero and a filter for "5+ years" removes you before any human sees the file.

Dates fail to parse for mundane reasons. Letter-spaced typography in design templates writes "0 9 . 2 0 2 3" as separate characters. Two date formats in one document make the pattern ambiguous. A date placed in a right-hand column far from its job title may be associated with the wrong role, or with none. An entry with a title and a company but no dates at all — Resuzu's GEN-04 — is invisible to the timeline calculation entirely.

The fix is unglamorous: one date format, written as text, on the same line or the line directly below the role it belongs to, for every entry including education.