How applicant tracking systems actually work

An applicant tracking system is fundamentally a database with a parser attached. It ingests your resume, tries to extract structured fields — name, contact details, employers, dates, titles, skills, education — and stores the result so recruiters can search and filter.

It is worth correcting a persistent myth: mainstream systems do not assign a secret score and auto-reject below a threshold. What actually happens is more mundane and, in practice, worse. A recruiter searches for the skills they need, and you either appear in the results or you do not.

That reframes the problem. You are not trying to satisfy an algorithm. You are trying to be findable, and to be parsed correctly enough that your experience is legible when a human does open the file.

The distinction matters because it changes what you should spend time on. If you believe a score is gating you, you optimise for a number nobody is computing. If you understand that a recruiter is running a search, you optimise for appearing in it — which is a concrete, checkable goal.

Once a posting closes, or while it is still open, a recruiter working through a few hundred applications does not read them in order. They run searches against the parsed fields — a required technology, a qualification, a location, a seniority band — and work through whoever comes back.

Those searches are usually narrower than the job description. A posting may list fifteen requirements, and the recruiter searches on the two or three that are genuinely non-negotiable. Everyone who does not surface for those two or three is, for practical purposes, not in the process at all.

This is why a resume can be excellent and still produce silence. It was never rejected; it was never retrieved. And nothing in the process tells you which of the two happened, which is what makes the experience so opaque from the outside.

The most common cause is parsing failure, not competence. If your work history sits inside a table, a text box, or a two-column layout, many parsers read it in the wrong order or drop it altogether. Contact details placed in the document header are routinely invisible.

The second cause is vocabulary mismatch. If a posting asks for "React" and your resume says "front-end frameworks", a keyword search will not surface you. That is not dishonesty on either side; it is two different words for the same thing, and the search does not know that.

A third, quieter cause is date formatting. Parsers use dates to compute how long you spent in each role and how recent your experience is. Inconsistent or ambiguous formats — "03/04/2024" means two different months depending on where you are — produce a garbled work history that undercuts your seniority without anyone noticing.

• Multi-column layouts that scramble reading order
• Tables and text boxes the parser skips entirely
• Contact details in a header or footer region
• Scanned or image-based PDFs with no text layer
• Non-standard section names like "My Journey" instead of "Experience"
• Skills present in the role but absent from the wording
• Inconsistent date formats that garble the computed timeline

The rules are boring, which is the point. A single-column, reverse-chronological layout with conventional section headings parses correctly in essentially every system in common use.

Export as a text-based PDF unless the posting explicitly asks for .docx. You can verify the text layer in ten seconds: open the PDF, try to select your name with the cursor. If it does not highlight as text, no parser can read it either.

Design restraint is not a stylistic preference here. Every graphical element that carries meaning — a skills bar chart, an icon standing in for a section heading, a sidebar of contact details — is information the parser cannot recover. If removing the styling would lose content, the styling was doing work it should not have been doing.

Mirror the job description’s own vocabulary where it is genuinely true of you. If it says "PostgreSQL" and you wrote "SQL databases", change it. If it names a methodology you have actually worked in, use their term for it.

Keyword stuffing — hidden white text, a wall of unrelated technologies — is both easy to spot and counterproductive. Recruiters do open the file, and a skills section listing forty technologies signals nothing except padding. Depth in the handful that match the role is far more persuasive.

The reliable technique is additive rather than substitutive. Write the phrase you would naturally use and the phrase the posting uses, in the same sentence, where both are accurate: "built and operated ETL data pipelines" satisfies a literal search for ETL and still reads like a person wrote it.

Where you genuinely lack a required skill, the honest move is to leave it out. A keyword you cannot defend gets you into a technical conversation you will lose, which costs more than the application would have.

There is one place in the process where automatic rejection is real, and it is not the resume parser. Application forms frequently include knockout questions: do you have the right to work here, do you hold this licence, do you have at least this many years of experience, can you work from this location.

Answering one of those the wrong way can remove you from consideration immediately, regardless of how good the rest of the application is. These are configured by the employer, they are binary, and they are applied before a human sees anything.

The practical implication is to read the form as carefully as the posting. A question about years of experience with a specific technology is asking something narrower than total career length, and an answer given carelessly is not recoverable later.

• Right-to-work and sponsorship questions
• Minimum years of experience with a named skill
• Required licences, clearances or certifications
• Location and on-site availability
• Notice period and earliest start date

Rather than guessing, compare your resume against the specific posting. A checker parses both documents the way an ATS would, surfaces the required skills that are missing from your resume, and shows which sections are thin.

Two minutes of that before submitting is worth more than another hour of formatting. Once the gaps are visible, closing them is usually a matter of rewording things you have genuinely done.

There is also a free version of this test you can run yourself. Copy the text out of your own PDF and paste it into a plain text editor. What you see is approximately what the parser sees — and if the order is wrong, a section is missing, or your phone number has vanished, you have found the problem before an employer did.