Applicant tracking systems

Two different things get called “ATS support.”

One is reading a system, so a job reaches you from the source instead of a job board’s copy of it. The other is filing through it, so an application lands in the recruiter’s pipeline with every field mapped and every file in the right slot. We do the first across 17 systems and the second across 4 - and we’d rather show you the line than blur it.

The whole distinction, in one screen

Reading is a wide net. Filing is a narrow, deep one. They are not the same promise.

Lane one · Read17 systems

The posting comes from the employer’s system, not a copy of it

Every system on the roster is polled directly on an hourly cycle. That’s earlier than a job board - not because the clock is faster, but because the chain is shorter.

01Req opens in their system
02Hourly crawl reads the board · 5 at a time
03Deduped, matched, in your feed
04Gone from the board? Expired overnight
  • Postings, salary bands, locations and req IDs read from the source, not from an aggregator.
  • 15 of the 17 through a documented keyless API; the rest from public pages, because no feed exists.
  • Re-posts and quiet closures picked up on the same pass, so dead listings drop out overnight.
Lane two · Filed4 promised

The application lands in the recruiter’s pipeline

Greenhouse, Lever, Ashby and Workable. A browser session fills the employer’s own public form - the same one you’d have filled - and captures what comes back.

  • Résumé in the résumé slot, cover letter in the cover letter slot - never both pasted into a notes box.
  • Screening questions it can’t answer truthfully are asked once and banked, never guessed.
  • The employer’s confirmation page is asserted and photographed - proof it arrived, rather than a hopeful “sent”.
  • 6 enterprise systems have no guest lane at all. Those come back to you, documents in hand.
attempted on their public form · 7 MORE, BEST EFFORT
no guest lane, handed back · 6 SYSTEMS
On this pageWhat an ATS actually isThe roster, system by systemHow your résumé gets read
Start herePlain english

What an applicant tracking system actually is.

If you’ve applied for a job in the last decade you’ve used one - you just weren’t told its name. Here’s the whole idea in about ninety seconds.

An applicant tracking system is the software an employer uses to run hiring. It holds the job posting, it hosts the form you fill in, it stores your résumé, and it’s where every candidate sits in a list that recruiters move through stages: applied, in review, interview, offer.

The important part for you: the ATS is the employer’s tool, not a gatekeeper you can appeal to. There is no ATS company scoring you. Each employer configures their own - which questions get asked, which answers disqualify, who gets notified, how results rank when a recruiter goes looking.

Two things follow. First, the posting exists in the ATS before anywhere else - job boards are downstream copies, which is why they lag. Second, your résumé is read by software before a person opens it, so how it’s formatted decides what a human ever sees.

The myth worth dropping: “the ATS rejected me” is almost never what happened. Automatic rejection fires only on explicit knockout questions an employer set - work authorisation, a required licence, a location. Everything else is a human deciding, usually after a keyword search your formatting either survived or didn’t.
One application, end to endgreen = where LandEarly touches it
1
A requisition opens
A hiring manager gets approval and the role goes live in the company’s own system. This is the moment worth watching - and the moment nothing downstream knows about yet.
2
It syndicates outward
The posting is pushed to the careers page, then to job boards and aggregators - hours or days later, in whatever order those feeds happen to run.
3
We read it from the source
The hourly crawl asks each employer’s board directly rather than waiting for a syndication feed. That’s the actual advantage: a shorter chain, not a faster clock.
4
You apply
A form in their system. Files are uploaded and parsed into fields - which is where a well-designed résumé quietly loses information it never gets back.
5
You become a record
Name, contact, work history, answers, attachments and a source tag, sitting in a stage, waiting to be looked at.
6
A recruiter filters
Usually by keyword and required answers, over a few hundred records. Anything that parsed badly is hard to find here - not rejected, just not surfaced.
7
Your stage changes
Rejection, screen, interview. Most systems email you at some of these, and reading those replies is how your tracker moves without you.
Requisition

The employer’s internal record of one approved open role. The posting you see is its public face.

Parsing

Turning your uploaded file into text, and then into fields. Where most résumé problems actually happen.

Knockout question

A question with a disqualifying answer the employer set - work authorisation, a licence, a location. The only true auto-reject.

Pipeline stage

The column you sit in. Moving stages is a person’s action, and usually triggers the email you get.

The rosterEvery system, one capability level

17 systems read. 4 filed through. Here’s which is which.

Pick any system to see how its board is actually read, what applying there is like, and what stops us where something does. Each tile names the adapter behind it, so this is checkable rather than assertable - the count itself is derived from that list, and the page fails to build if the two disagree.

Coverage moves. Systems get added, employers migrate mid-search, and a lane can change when a vendor changes what’s public - when that happens the tile changes here and in your account on the same day, and any affected application is flagged on your timeline rather than quietly retried. Names are the trademarks of their owners; a tile states what we can read or send, not a partnership or an endorsement.

Where the line is

Four lanes, and what each one actually buys you.

The interesting one is the third. A draft of this page had two lanes - watched and submitted - which quietly filed six enterprise systems under “you apply on their site”. What really happens there is better than that, and worth its own name: the run stops before the login wall rather than failing at it.

Filed for you - promised

The four systems the rest of this site names. A browser session fills the employer's own form, the confirmation page is asserted and photographed, and the run is covered end-to-end by tests against a mock of each one.

Filed for you - best effort

The same machinery, pointed at a public form we haven't built a mock for. It runs and it usually works - Recruitee even goes through a native endpoint in production - but it isn't what we promise, so it's labelled for what it is.

Handed back to you

No guest lane exists: applying means creating an account behind a CAPTCHA. Rather than spend a browser session hitting a login wall and calling it a failure, the pipeline stops early and gives you the tailored documents to finish with.

Not watched - paste to track

A bespoke careers page on no recognisable system. Nothing crawls these, so nothing can spot one first - but paste a URL and the job is tracked, tailored and attempted like any other.

What proof of a submission looks like.

The handoff for this page promised a submission ID returned by the ATS. None of these systems returns one to us. What there is instead is arguably better, because you can look at it.

What comes back when one lands
  • A confirmation page matched against known receipt copy
  • …and checked for error markers, so a silent failure can't read as success
  • A screenshot of that page, stored on the application
  • The submitted event on your timeline, with its time

NOT an API submission id. Nothing here is a number a vendor handed us - it is their own confirmation page, matched against known receipt wording and checked for error markers, so a submit that silently didn’t land can’t be recorded as one that did.

And what happens at a question it can’t answer.

Every application form has a few. The rules below run in order, and the last two are the ones worth knowing - a protected-class question is handled differently from everything else on purpose.

The four ways a screening question endsin this order
1
An answer it has, matched exactly
Your banked answer, matched case-insensitively against the option list. Filled without asking you.
2
One unambiguous near-match
Whole-word containment, and only when exactly one option matches. Two matches is treated as no match - otherwise “United States” picks “United States Minor Outlying Islands”.
3
A protected-class question
Exact match only - the near-match step is skipped entirely, because “Hispanic or Latino” is contained inside the opposite option, “No, not Hispanic or Latino”. Anything less than exact takes Prefer not to say, never a guess.
4
Anything it can't answer truthfully
It stops and asks you, once, and banks the answer for next time. The comment on that guard is the whole policy: a silent wrong answer to an employer is never recoverable.
The parsing angleIngest

Your résumé is read twice - by software first, and it doesn’t see what you see.

Before a recruiter opens your file, the system flattens it to text and pulls structured fields out of it. A layout that looks considered on screen can arrive as interleaved lines, empty contact fields, and skills welded into one unsearchable string. Below is the same file both ways, scored by the same rubric our free checker uses - a pure function, so we can show you its working.

The file you uploadedtwo columns · clever headings
header region
Marcus Ade
marcus.ade@fastmail.com+1 415 555 0138
Where I’ve been
Senior Engineer · Corvid
Mar ’22 – Present
Pulled billing out of a Rails monolith serving four million requests a day with no maintenance window.
Engineer · Halterway
’19 – ’22
Owned the payments service end to end, and the ledger behind it.
Stack
GoPostgresKafkaTerraformRuby
References available on request · page 1 of 2
…and the text an extractor got out of it
Marcus Ade

Where I've been                    Stack
Senior Engineer · Corvid  Mar '22  GoPostgresKafkaTerraformRuby
Pulled billing out of a Rails monolith serving four
million requests a day with no maintenance window.

Engineer · Halterway      '19 – '22  Postgres Ruby
Owned the payments service end to end, and the
ledger behind it.

Schooling
BSc Computer Science · University of Bristol

References available on request · page 1 of 2
The same four checks, both fileslib/ats-scorer.ts
CheckTwo columnOne column
Parseable text and contact details×30%3080
Standard section headings×28%070
Role-relevant keywords×24%934
Formatting and length×18%4040
Score1859

41 points, and not one of them is about what the résumé says. Same person, same roles, same claims, word for word. What changed is one column instead of two, plain headings instead of clever ones, and contact details in the body rather than the document header.

Both files also miss the same content marks, which is the other half of the argument. The checker finds one action verb on its list in either version (“owned”; “pulled” and “took” aren’t on it), and not one quantified result - “four million requests a day” is spelled out in words, so the parser is never handed a digit.

Break 01

Columns are a suggestion

Extraction runs left to right across the whole page. Two columns become interleaved lines, and a skills list ends up inside a job title.

Break 02

Headers, footers, text boxes

These live outside the main text flow. Contact details put there are frequently never extracted at all - take the email and phone out of the file above and it drops 15 points, lost to a design choice.

Break 03

Tables weld words together

Cell boundaries vanish on export. Five clean skills arrive as one unsearchable string, and a keyword filter for “Kafka” never matches it.

Break 04

Icons carry no text

A little envelope glyph is an image. If your email address is labelled only by an icon, the field it should fill is simply blank.

Break 05

Creative headings don't map

Parsers match a fixed vocabulary, and so does our own checker. “Where I’ve been” is invisible where “Experience” is understood - swapping that one heading costs 7 points on its own.

Break 06

A PDF can be a picture

Design tools sometimes export text as outlines or a flat image. The file opens perfectly for you and contains zero characters for the parser.

Run your own file through the same rubric - free, no account.

The Resume ATS Checker runs exactly the four checks scored above and tells you where your own file loses its points. It’s a floor, not a verdict - it catches structure, not judgement - and in the example above, structure was worth 41 points.

Check my résumé
The unglamorous half

What this page is careful not to say.

Coverage claims are easy to inflate and hard for you to check, so here are ours stated in the negative. Four of the six were on a draft of this very page, which is the honest reason this section exists.

Not claimed

“Forty-one applicant systems”

A draft of this page said forty-one, with per-system polling schedules down to the minute. There are seventeen adapters, they are the ones listed above, and every one of them is polled on the same hourly cycle. The number on this page is derived from the adapter list, so it can’t drift from it.

Not claimed

“We apply to Workday for you”

We don’t, by default. Workday wants an account per employer, and its apply page opens a chooser with no fillable controls at all. You get the tailored documents and finish it - and the run stops before burning a browser session on a login wall.

Not claimed

“Integrated with every system we watch”

Reading a board and filing an application are different problems with different answers. Seventeen are read. Four are promised for filing, seven more are attempted on their public forms, and six have no guest lane to attempt.

Not claimed

“The posting reaches you in four minutes”

One cron runs hourly across every board. The honest claim is a shorter chain, not a faster clock: we ask the employer’s system directly instead of waiting for it to syndicate to a job board, and a posting reaches you within the hour rather than whenever a feed catches up.

Not claimed

“We beat the ATS”

There’s nothing to beat, and no vendor is scoring you. We shorten the path to a posting and make sure your file parses cleanly. No keyword stuffing, no white text, nothing that gets a record flagged by the person who eventually reads it.

Not claimed

“The extension fills the forms”

It doesn’t - that one was in the draft too. The browser extension is a new-tab job feed and a one-click posting decoder; it has no autofill in it. On a system we hand back, the form is yours to fill.

Greenhouse, Lever, Ashby and Workable, Workday, SuccessFactors, iCIMS, Oracle, ADP, UKG, SmartRecruiters, Recruitee, Teamtailor, BambooHR, Personio, Breezy, JazzHR and every other name on this page are trademarks of their respective owners. LandEarly is not affiliated with, endorsed by, or sponsored by any of them; where we file applications, we do so through the employer’s own public application form or a documented public interface, on your behalf and at your instruction.

Asked directly

The questions this page owes you.

How do I know which system a job uses, before I care?

Every posting shows it, along with what LandEarly can do with it. If it’s one of the 4 we file through you’ll see a submit button; if it’s one of the 6 that need an account, you’ll see the documents and a link to their form. No ambiguity at the point of decision - which matters more than the total on this page.

Is applying through you worse than applying direct?

It’s the same form. A browser session fills the employer’s own public application - the one you’d have filled - and the record it creates is the record you would have created. What differs is that it takes a minute instead of twenty, and the confirmation page is captured so tracking has something real to work from.

Will the recruiter see it came from a tool?

They see a candidate record with your details and your documents. Source attribution is whatever the employer’s own configuration assigns to that channel - we don’t add a badge, and we don’t hide anything either.

Does a posting really reach me faster than on a job board?

Earlier, by a shorter route rather than a faster one. The crawl is hourly and makes no promise below that - but it reads the employer’s system directly, while a job board is waiting on a syndication feed that may take a day. A draft of this page claimed a four-minute median; there is no such measurement, and an hourly cron couldn’t produce one.

Why won't you apply to Workday for me?

Because there’s no guest lane to apply through - Workday wants an account per employer, and its apply page opens a chooser with no fillable controls on it. A flow that handles this does exist, with vaulted credentials and a per-employer consent step, and it is off by default until it’s switched on for you. Until then you get the tailored documents and finish it yourself.

My résumé scored badly. Is that the ATS's fault?

It’s a formatting mismatch, not a verdict on you - in the example on this page, 41 of the points came back from changing nothing but the layout. Start with the free checker, then let tailoring handle the wording.

Applicant tracking systems

Be early where we read. Be effortless where we file.

17 systems read at the source, 4 filed through on your behalf, and a free checker for the file every one of them has to read.

17 read · 4 filed · 7 best effort · 6 handed back