How applicant tracking systems really work

In a survey of 2,275 executives in the United States, the United Kingdom and Germany, 63 % said their companies used recruiting software, more than 90 % of those companies used it to filter or rank candidates first, and 88 % believed that qualified high-skills candidates were screened out because they did not match the exact criteria of the job description. Software does shape who gets read, but what it does is narrower, and easier to check, than most advice suggests.

This lesson takes one kind of system apart with its vendors’ own documentation: what parsing does, the form rules that can reject an application, the exact-match search that recruiters run, what AI ranking does and does not do, and the laws that now govern such tools. Then it checks ten common claims against those sources.

Parsing fills a profile, and a failed parse is not a rejection

The software that holds applications is an applicant tracking systemapplicant tracking system: Software an employer uses to receive applications, store resumes, fill candidate profiles from them, search them and move candidates through the stages of hiring.. When a resume arrives, it keeps the file, extracts its text and parses it: it looks for the name, the contact details, the jobs and the education, and copies each into a field of the candidate’s profile. Step through one upload:

Greenhouse, one widely used system, documents what happens when resume parsingresume parsing: Reading a resume file with software to copy details such as the name, contact details, jobs and education into the fields of a candidate profile. goes wrong. A resume it cannot parse is only attached to the candidate, and someone fills in the profile by hand. It cannot parse files larger than 2.5 MB. And it lists the layouts that lead to a partial parse:

• spaces between the letters of words;
• graphics, photos or word art, and a resume uploaded as an image instead of a document such as .docx or .pdf;
• complex resumes with tables, headers and footers, the name and contact details in a header, footer or text box, or the page set in columns;
• sections that are not clearly marked, or formats that differ within a section.

None of these is a rejection. A partial parse means empty or wrong fields that a person corrects, while a resume with no text at all, a photo or a scan, gives the search in the next sections nothing to find. The formatting lesson of this track measures what each of these layouts does to the extracted text.

Form rules, not formatting, are what reject automatically

Automatic rejection comes from the application form. Greenhouse’s auto-reject rules act on a job post’s yes or no, single-select and multi-select questions: the employer chooses the answer that rejects, and an applicant who gives it is rejected automatically, with the rejection reason the rule assigns, and sent a rejection email if the rule is set to send one. Greenhouse’s own example is a job that needs a commercial driver’s licence. A question used this way is a knockout questionknockout question: An application-form question whose answer can end an application by itself, such as whether you hold a licence or a right to work that the role requires., and these are typical ones:

Rules can act on what the resume shows, too. In the Hidden Workers survey, almost half of the employers screened out resumes with a gap of more than six months in the work history, so that no recruiter ever saw them. Such filters are set by the employer. They are reasons to answer every question accurately and to account for a long gap, not reasons to redesign the page.

Recruiters search the text, and the search is exact

Once applications are in, a recruiter can search them. Greenhouse’s talent filtering looks for the words a recruiter types, such as job titles, skills and places, anywhere in the text of the resumes and in the team’s internal notes, and its documentation is specific about matching: a keyword “must exactly match the keyword in the application”. This is an exact matchexact match: A search rule under which a keyword counts only when the same word appears in the text. A synonym, an abbreviation or another spelling does not count.. Keywords can be preferred, where any one of them is enough (an OR), or required, where all of them must appear (an AND), and filters then narrow the results by location, referrals and education.

The program applies a form rule and then that search to four invented applications. Press Edit, change a resume or the search, and run it again:

# Four invented applications to one posting, run through two documented kinds of rule: an auto-reject rule on a
# yes/no form question (Greenhouse's auto-reject acts on yes/no and select answers), then a recruiter's keyword search
# (Greenhouse's talent filtering: a keyword must exactly match the application; every required keyword must appear,
# and at least one preferred keyword). A model of the documented rules, not any vendor's code.
# Press Edit, change the resumes, the answers or the search, and run it again.
import re

REQUIRED = ["Python", "PostgreSQL"]  # every one must appear (AND)
PREFERRED = ["Kafka", "Kubernetes"]  # at least one must appear (OR)
KNOCKOUT = "Can you work from the Pune office three days a week?"  # the posting rejects the answer "No"

APPLICATIONS = {
    "Asha": {"answer": "Yes", "resume": "Backend engineer. Python and PostgreSQL services; Kafka consumer for 2 million events a day."},
    "Ravi": {"answer": "Yes", "resume": "Backend developer. Python and Postgres services on Kubernetes, 99.9 % uptime."},
    "Meera": {"answer": "Yes", "resume": ""},  # she uploaded a photo of her printed resume: no text to search
    "Kiran": {"answer": "No", "resume": "Senior engineer. Python, PostgreSQL, Kafka and Kubernetes at scale."},
}


def has(term, text):
    """The keyword as a whole word of the text: "Java" is not found in "JavaScript", nor "PostgreSQL" in "Postgres".
    Letter case is ignored here; the article does not say whether it counts."""
    return re.search(rf"(?<![\w-]){re.escape(term)}(?![\w-])", text, re.IGNORECASE) is not None


print(f"Form rule: answering No to {KNOCKOUT!r} rejects the application.")
print(f"Search: all of {', '.join(REQUIRED)}; at least one of {', '.join(PREFERRED)}.")
print()
for name, application in APPLICATIONS.items():
    resume = application["resume"]
    if application["answer"] == "No":
        print(f"{name:<6} rejected by the form rule; the search never runs on this resume")
        continue
    if not resume:
        print(f"{name:<6} not shown: the file has no text, so no keyword can match")
        continue
    missing = [k for k in REQUIRED if not has(k, resume)]
    preferred = [k for k in PREFERRED if has(k, resume)]
    if missing:
        print(f"{name:<6} not shown: missing the required {', '.join(missing)}")
    elif not preferred:
        print(f"{name:<6} not shown: none of the preferred keywords")
    else:
        print(f"{name:<6} shown: required {len(REQUIRED)} of {len(REQUIRED)}, preferred {', '.join(preferred)}")

# Ravi has the skill; only the spelling differs. Writing the posting's own term fixes it.
fixed = APPLICATIONS["Ravi"]["resume"].replace("Postgres", "PostgreSQL")
print()
print(f"Ravi, with 'PostgreSQL' written as the posting writes it: {'shown' if all(has(k, fixed) for k in REQUIRED) else 'not shown'}")

Form rule: answering No to 'Can you work from the Pune office three days a week?' rejects the application.
Search: all of Python, PostgreSQL; at least one of Kafka, Kubernetes.

Asha   shown: required 2 of 2, preferred Kafka
Ravi   not shown: missing the required PostgreSQL
Meera  not shown: the file has no text, so no keyword can match
Kiran  rejected by the form rule; the search never runs on this resume

Ravi, with 'PostgreSQL' written as the posting writes it: shown

Ravi has the same skill as Asha and is not shown, because his resume says Postgres and the search says PostgreSQL. Meera is not shown because her photographed resume has no text, and Kiran’s resume is never searched, because the form rule rejected her application first. Writing the posting’s own term for a skill he has fixes Ravi’s case without adding a single new claim.

AI ranking sorts candidates, and people still decide

Newer systems add AI that compares applications with the role. In the documentation of the two features below, it sorts and suggests; it does not decide:

Two conclusions follow. Keyword stuffing is not a strategy: Greenhouse explains that several resume terms can map to the same calibrated skill, so more matched terms do not always raise a match. And a candidate can sometimes ask to be assessed without AI: Talent Matching has an optional opt-out that an employer’s administrators can switch on, after which the application is labelled for manual review and assessed by the team’s usual process.

Laws now govern automated hiring tools

Automated hiring tools are no longer unregulated, and neither is the data in your resume. Walk through the laws in the order they were made and began to apply:

For a candidate, two of these change what an employer must do. In New York City, an employer that uses an automated employment decision tool needs a bias auditbias audit: An independent check of whether an automated hiring tool selects or scores people differently by sex, race or ethnicity, which New York City requires before an employer uses such a tool. of it within the past year, a public summary of the results and a notice to candidates, and the city takes complaints. In the EU, AI that analyses and filters job applications is high-risk, and the Commission says the strict obligations for such systems apply from late 2027.

Ten common claims, checked against the sources

Much advice about tracking systems repeats claims that their documentation does not make. Here are ten, each with what the sources of this lesson actually say:

The last claim is the most repeated, and no study is given when it is. Treat a number like it as unsupported until someone shows where it was measured, and judge advice about tracking systems by whether it names its source.

Practise: write the search a recruiter runs

Build the search of this lesson yourself: every required keyword, at least one preferred keyword, whole words only. The sample tests use the lesson’s four applications and a few edge cases:

import re


def shown(text, required, preferred):
    """True when every required keyword and, if any are given, at least one preferred keyword appear in text."""
    # Replace this line with the search.
    return False

from search import shown

REQUIRED = ["Python", "PostgreSQL"]
PREFERRED = ["Kafka", "Kubernetes"]
ASHA = "Backend engineer. Python and PostgreSQL services; Kafka consumer for 2 million events a day."
RAVI = "Backend developer. Python and Postgres services on Kubernetes, 99.9 % uptime."


def test_every_required_and_one_preferred():
    """shows Asha, who has both required keywords and one preferred keyword"""
    assert shown(ASHA, REQUIRED, PREFERRED) is True


def test_a_different_spelling_is_not_a_match():
    """does not show Ravi: Postgres is not PostgreSQL"""
    assert shown(RAVI, REQUIRED, PREFERRED) is False
    assert shown(RAVI.replace("Postgres", "PostgreSQL"), REQUIRED, PREFERRED) is True


def test_a_missing_preferred_keyword_hides_the_application():
    """does not show an application that has the required keywords but none of the preferred ones"""
    assert shown("Python and PostgreSQL scripts.", REQUIRED, PREFERRED) is False
    assert shown("Python and PostgreSQL scripts.", REQUIRED, []) is True


def test_case_does_not_matter():
    """finds python in any letter case"""
    assert shown("PYTHON, postgresql and kafka.", REQUIRED, PREFERRED) is True


def test_whole_words_only():
    """does not find Java inside JavaScript"""
    assert shown("Five years of JavaScript.", ["Java"], []) is False
    assert shown("Java and JavaScript.", ["Java"], []) is True


def test_hyphens_belong_to_the_keyword():
    """finds infrastructure-as-code only with its hyphens"""
    assert shown("Terraform for infrastructure-as-code.", ["infrastructure-as-code"], []) is True
    assert shown("Terraform for infrastructure as code.", ["infrastructure-as-code"], []) is False


def test_no_text_matches_nothing():
    """does not show a photographed resume, which has no text"""
    assert shown("", REQUIRED, PREFERRED) is False

Then answer questions on all six ideas, from parsing to the claims table; each new question goes to the idea you are least sure of:

Interview questions

Warm-up (fresher to mid-level): What does an applicant tracking system do with your resume?

It stores the file, extracts its text and parses it, copying details such as your name, contact details, jobs and education into the fields of a candidate profile, and it makes the text searchable. Recruiters then search that text for keywords, which in documented systems must match exactly. What rejects an application automatically is usually a rule on the form, such as a required yes or no question, not the layout: a resume that fails to parse stays attached and is filled in by hand. AI features in documented systems sort applicants into match categories, but people make the decisions.

Two module questions take this further:

Key takeaways

• An applicant tracking system stores your file, extracts and parses its text into profile fields and makes it searchable; a failed parse is not a rejection, but a file with no text cannot be searched.
• Automatic rejection comes from rules on form answers, such as a required yes or no question, so every answer must be accurate.
• Recruiter searches are exact: write the posting’s own name for each skill you have.
• AI ranking in the documented systems sorts and suggests, and more matched terms do not always raise a match.
• New York City requires yearly bias audits of automated hiring tools, the EU treats AI that filters applications as high-risk, and data protection law gives you rights over the data in your resume.