Resources / Original research

We uploaded the same resume to 4 ATS platforms. Here's what candidates actually see.

We ran one fictional resume through live application flows on Lever, Oracle Taleo, Workday, and Greenhouse, recorded every candidate-visible field, and stopped before final submission. The biggest difference was not accuracy. It was whether the system showed us any parsing result at all.

How we tested—and what this can prove

The setup was deliberately narrow:

• One fictional senior product and engineering resume, prepared as a single-column DOCX and text-based PDF with standard fonts, headings, and no graphics or tables.
• Four live job postings: a fintech lender on Lever, an energy company on Taleo, a large entertainment company on Workday, and a fintech startup on Greenhouse.
• We logged the fields each application displayed, whether a value was correct, and whether its source could be attributed to the resume. Testing took place in July 2026.

The core finding: a candidate-side observability spectrum

The four applications exposed radically different amounts of evidence about what happened after upload:

On the Greenhouse application we tested, the candidate-facing flow exposed zero parsing output. That is evidence of zero visibility—not evidence of zero background parsing.

We call this range the candidate-side observability spectrum. It determines what you can verify inside an application. It also explains why a third-party “ATS compatibility” score cannot represent the behavior of a specific employer's ATS instance: the tool is grading a proxy, not observing that instance. See our analysis of what an ATS score actually measures.

What each system did

Lever: clean, correct, and shallow

Both files uploaded successfully in the Lever flow. The same seven visible values were correct: name, email, phone, current location, current company, and LinkedIn URL. The phone number was normalized, and the location was expanded to include the country.

That result only covers what the form revealed. Work history, dates, education, skills, and certifications were not displayed as structured candidate fields. We therefore could not evaluate whether Lever parsed them in the background.

Oracle Taleo: the most evidence and the most visible errors

Taleo exposed the richest candidate-visible structure, spread across an 11-step flow. Both work-experience entries appeared with employer, title, date range, and most responsibility text. Education level, school, and major also appeared.

The same flow duplicated one phone number into Home, Cellular, and Work fields; marked the current role as not current; added an education location and graduation date that were not in the resume; dropped a certification; and flattened bullet structure. The final review also contained address data whose source we could not identify.

Of roughly 18 attributable fields in this case, 12 were complete, 1 was partial, and 5 were missing or wrong. That ratio cannot be generalized. The reusable insight is the error pattern: duplication, wrong status flags, phantom values, flattened text, and dropped sections are exactly what to inspect on a long pre-filled form.

Workday: resume data met account and region rules

Workday's “Autofill with Resume” surfaced a name, city, and phone number. The candidate account's country or region then triggered localized name and address fields plus phone validation for a different country code, which rejected the resume's valid US number.

In this case the final form was a blend of resume extraction, account data, regional rules, and manual input. That makes a Workday account audit especially important when applying across countries or reusing an older profile.

Greenhouse: a candidate-side black box

The Greenhouse posting accepted the resume as an attachment. Name, email, and phone still required manual entry, while company, title, experience count, dates, education, and skills were not displayed as structured fields.

This does not mean Greenhouse parsed the resume poorly. It may have produced a useful recruiter-side profile. The defensible conclusion is narrower: this candidate flow gave us no observable parsing output to judge.

Why “does my resume pass the ATS?” is the wrong question

The parser layer extracts text and maps it into fields. The employer configuration layer controls which fields you see, which questions are required, how the workflow is localized, and how many steps exist. A candidate then sees only the slice the application exposes.

Two employers using the same ATS can create different experiences. Even the same employer can configure two postings differently. “We tested Workday” therefore cannot mean “we tested your Workday application.” A useful pre-application check can estimate general parseability and keyword coverage, but it cannot predict the complete behavior of a specific employer setup.

Six actions supported by the evidence

1. Use a conservative format as cheap insurance. Choose one column, standard headings, body-text contact details, and a DOCX or text-based PDF. This reduces avoidable risk; it does not guarantee a result.
2. Treat pre-filled data as a draft. Check duplicates, current-job flags, dates, locations, certifications, and any value you did not write.
3. Continue checking on multi-step forms. Taleo surfaced structured data and errors several steps after upload.
4. Audit your Workday account. Region, email, and historical profile data can conflict with the current resume.
5. Optimize black-box flows for the human reader. When parsing output is not visible, a clear and evidence-rich resume remains the controllable asset.
6. Use scores as diagnostics, not pass probabilities. A precise number cannot tell you what a specific employer instance will do.

The eight-state framework we used

Every field received one state. The last two categories prevented us from turning missing visibility or mixed data sources into false parser failures.

FAQ