The Same Resume Can Be Findable in One System and Invisible in Another
Pascal George
Synthalyst Author
Most advice about applicant tracking systems assumes there is one system, working one way, that you can either beat or not beat.
There isn’t. There are at least three different mechanisms deciding whether a recruiter ever sees your name, and they work so differently that a resume tuned for one can be made worse for another.
That is the part nobody explains, and it is the part that decides whether your application gets looked at.
Everything below comes from the platforms’ own published documentation. Sources are at the bottom, and you can check every one.
First, the myth worth dropping
An ATS (applicant tracking system, the software companies use to collect and manage applications) is mostly a database. It stores applications, tracks stages, and lets recruiters search.
It is not an artificial intelligence reading your resume and rejecting you. The widely repeated claim that a large majority of resumes are auto-rejected before a human sees them does not hold up.
But “the ATS doesn’t reject you” gets misread as “the ATS doesn’t matter.” It matters enormously. It just does not work the way the myth says. It does not turn you down. It fails to return you.
Before any of the three: your text has to come out of the file
All three mechanisms below work on the text of your resume. Not the document you designed. The text a piece of software managed to pull out of it.
That extraction happens before a person sees anything, and it is the step nobody checks. The old advice was to avoid PDFs because the software could not read them. That was true once and mostly is not anymore. The format was never the real question. The question is whether the words survive being pulled out.
There is a one-minute way to see what the software sees. Open your resume, select everything, copy it, and paste it into a plain notes file with no formatting. Then read what came out.
Is everything there? Is it in the order you meant? Are your name and contact details in the text, or did they vanish because they sit in the document header? Do your dates still sit next to the right jobs?
If the paste reads clean, your file is fine, in either format. If it comes out scrambled, the usual causes are text in two columns, which can paste in the wrong order, tables, which can separate your dates from your jobs, contact details in the header, which some systems skip, and words baked into a graphic, which do not come out at all.
A clean single-column resume passes this test either way. Nothing further down this page can help a resume whose text does not survive the first step.
Mechanism one: a recruiter typing into a search box
This is the highest-volume path between you and a hiring decision, and it is the least forgiving.
Greenhouse, a widely used hiring platform, publishes exactly how its candidate search behaves. A quoted phrase matches only that phrase, in that word order. Their own example: searching "senior engineer" returns only records carrying those words together, as a phrase.
Two consequences follow. Both open as ordinary keyword advice, and the part that actually costs people is in the last line of each.
Your exact wording has to match theirs. “Managed projects” does not match a search for “project management.” Same skill, same person, different string. You are not ranked lower. You are absent from the results.
The software will not think of your synonym for you. If a recruiter wants every version of a role, they have to type them out and join them manually, the way Greenhouse’s documentation shows: trainer OR instructor OR teacher. Nothing expands that automatically. If the recruiter does not personally think of your word, your record is not in that result set.
This is why “improving” a posting’s language is a trap. You read “project management,” you write “project leadership” because it reads stronger, and you have written yourself out of the search.
How badly does exact matching fail? LinkedIn’s engineering team gave the number when explaining why they rebuilt their search around meaning: keyword search “returned zero results for nearly half of queries.”
Half. On a database of over a billion profiles. The right people were in there, described in different words.
What our own testing adds
Both of the above come from a vendor’s own documentation. These come from a test we ran: eighty-four combinations of wording, search style and engine setting, covering quoted phrase searches and boolean ones, with word stemming switched on and off.
A credential written one way is invisible to a search for the other way. Daniel has held the PMP for six years and his resume says “PMP.” A recruiter searches for “Project Management Professional.” Daniel does not come back. Not lower down the list. He is not in the results. It works in reverse too: a resume carrying only the full name never comes back for a search for “PMP.” Write it as “Project Management Professional (PMP)” and it is returned for both, in either order. We could not construct a search where carrying both forms did worse than carrying one.
This is not an argument for stuffing your resume with variations. PMP and Project Management Professional are two standard names for one thing that you either hold or do not. If you hold it, both names are true and both belong on the page. If you do not, neither does. The same logic applies to degrees: a search for “Bachelor of Science” does not match “BSc.”
You do not have to delete your good sentence to carry their term. Maria’s resume says “Cut delivery time 30% across three business units.” It is a far better line than “project management” and it is invisible to a quoted search for that phrase. The fix is not to replace it. Put their term in front of it as a label:
“Project Management: Cut delivery time 30% across three business units”
We tested that shape. It is returned by a phrase search for “project management,” while the same outcome sentence without the label is not. Nothing about Maria’s evidence changed. Their phrase is now on the page, in their word order, attached to work she genuinely did.
One honest caveat on all of this. Everything above is about quoted phrase searches, which is what
Greenhouse documents. Our test found exactly one case that behaves differently: an unquoted search
for project AND management on an engine with word stemming turned on does match “managed projects.”
The quoted case is unaffected, and you cannot know which kind of search a given recruiter will type.
So, what should you do?
Write for the quoted search. It is the stricter of the two, and it costs you nothing to assume it: a resume carrying the posting’s exact phrase comes back for both kinds of search. A resume that only matches loosely comes back for one of them, and only if the recruiter happens to type it that way.
Mechanism two: a system scoring you against the job
Some platforms score applicants against the job automatically. Workday is the clearest documented case, and its administrator documentation is specific about what is being compared.
It does not compare your words to their words. It compares skills derived from what you submitted against skills derived from the job requisition, using machine learning to judge how similar the two sets are.
It is worth being exact about what “what you submitted” covers, because it is more than your resume. Workday’s documentation names two sources and two routes. The sources are your resume and the application form you filled in on their site. The routes are skills the system infers from both, and skills you typed in yourself on either.
So the form is not a formality you rush through after attaching the real document. A skill you left out of a dropdown is missing from the same pool as a skill you left off the resume.
Workday reads resumes in DOC, DOCX, HTM, HTML, PDF, RTF and TXT. A resume in a format outside that list is one of the documented reasons it cannot produce a score at all, so exporting to PDF or Word is the safe move if you write somewhere less common.
So here, unlike mechanism one, wording differently can survive. The inference layer exists precisely to bridge vocabulary gaps.
Five details from that same documentation are worth knowing, because none of them are obvious:
Required beats preferred. Workday “assigns greater weight to job applications with the required skills specified on the job requisition.” The distinction between must-have and nice-to-have is not cosmetic.
Recruiters see your gaps in a list. The system shows them “Skills Not Found,” the skills on the job posting that your application does not appear to cover. You never see this list, and you cannot answer it. Where the employer switches on the full score details, the recruiter can also open your education and certification details, your job experience details, and the matched skills split into required and everything else.
A thin application does not score badly. It does not score. Applications without enough skills information return “Low” or “Unable to Score.” A low score sits at the bottom of a ranked list where a recruiter might still reach it. No score is not on the list at all, and nothing tells you it happened.
Three things the score ignores completely. Workday’s own list: how recently you acquired a relevant skill, how long you used it, and your total years of work experience. None of the three enters this calculation. Whether a skill is evidenced at all is what counts here, not how seasoned you are in it.
Short evidence carries disproportionate weight. Workday’s engineers describe a service that takes compressed signals, a job title, a certification, education details, and expands them into the skills those signals imply. Their own illustration is the clearest way to see it: “if we were to mention that Jane has an MBA, you would be able to deduce a lot of information regarding skills Jane is likely to have based on just those three letters.” Three letters, a whole list of implied skills. The service caps that list at twenty.
That last point has a practical edge. A real job title and a named certification are dense signals a model expands. Three sentences of prose describing the same work are not. Rewriting a title into flowing description reads better to a human and carries less to the system.
So what do you actually do about mechanism two
Put the five together and they point one way: this system rewards coverage, not depth.
It does not measure how good you are at anything. It cannot. It has told you so itself, by ignoring how recently you used a skill, how long you used it, and how many years you have worked in total. What it measures is whether a thing is named somewhere in what you sent, and whether the requisition’s required items are among those things.
That inverts the usual advice for this one step. The standard instruction is to go deeper: fewer claims, more evidence, stronger proof on each experience bullet. Depth is invisible here. A paragraph proving you are excellent at one thing scores like one thing.
So the move is a coverage pass, and it takes about twenty minutes:
Read the posting’s required list, not the preferred list, first. For every item on it you can honestly back, make sure the thing itself is named in what you send, either on the resume or in the application form. A tool, a system, a platform, a method, a certification, a real job title. Not a sentence about having been responsible for it. Both places count equally, so a dropdown you skipped is a gap exactly like a line you left off the page.
Whatever you cannot honestly back, leave off. It goes on the recruiter’s Skills Not Found list either way, and the only thing you control is whether it is a gap or a claim you have to defend out loud at an interview.
One caution, because this pass can make a resume worse. Coverage is what this one mechanism rewards. A human reads next, and that person wants the depth. Add the named things to the work you already described. Do not trade your evidence for a longer list of nouns.
Mechanism three: searching for people who never applied
Mechanisms one and two act on people who applied. This one searches a whole database for people who did not. Treating the two situations alike produces a lot of bad advice.
LinkedIn runs two versions of this, and they do not behave the same way.
Its newer sourcing tools run keyword and meaning-based retrieval at once, then blend and re-rank the results. Its older recruiting product, still the more widely used of the two, is close to the opposite of the inference-based matching in mechanism two: it retrieves by exact match on standardized job title identifiers. Meaning-based expansion runs only when a recruiter search returns too few candidates, so for a common role with plenty of candidates it may never run at all.
That puts an uncomfortable amount of weight on one field. If your job title is invented, internal, or clever, you are not in the result set for the standard version of your own job.
One caution I will not gloss over: that architecture document is from 2019, and published sources do not say whether the product has been rebuilt since.
Across seven years, though, all three documents agree on what matters to you. Exact matching on standardized entities is still a live and load-bearing path in every one of these systems, including the newest.
What this actually means for your resume
Putting the three mechanisms together gives a short list, and it is more specific than the usual advice.
1. Check the file first. Copy your resume, paste it into a plain notes file, and read what comes out. Every step below assumes the text survives it.
2. Use their exact phrases, in their word order, wherever you can genuinely back the claim. Keep your own evidence line and put their term in front of it as a label rather than replacing what you wrote. This is the single highest-leverage move, because mechanism one is the most common and the least forgiving. Work down the posting’s requirements list item by item, starting with whatever it marks required rather than preferred, and for each one you can honestly back, check whether the posting’s own wording appears on your resume.
3. Never borrow language for something you cannot back. This is not a moral point, it is a practical one. Anything you cannot support falls apart at the first screening call, and the whole value of matching their vocabulary is that it surfaces work you actually did.
4. Keep real job titles and named certifications intact, labelled, and written in both forms. Do not dissolve them into prose, and write each certification and degree both in full and in its short form on the line where it already sits. They are compressed signals that get expanded into implied skills. Named skills matter for a different reason: on LinkedIn recruiters pick them from a list of standardized skills rather than typing them freely, so the standard name is the one that finds you.
5. Cover the named things, and do not trade depth for them. Name actual tools, systems, methods and certifications, because the scoring mechanism counts whether a thing is named rather than how deeply you can prove it. A resume that describes responsibilities without naming what you actually used is the profile that lands in “Unable to Score” territory, which is the one failure mode that’s never obvious. Add the names to your evidence rather than in place of it, because a person reads next and wants the evidence.
6. Cover the required list before the preferred list. They are weighted differently, and the gaps get itemized for the recruiter.
The honest limit
None of this makes an unqualified application succeed, and nothing here promises an interview. It is about a narrower thing: whether your resume is retrieved and assessed at all, so that being qualified gets a chance to matter.
That is the actual gap most people are losing to. Not being turned down. Never being returned.
If you would rather not do the phrase-by-phrase comparison by hand for every application, that is what Synthalyst Optimize is built for. You give it your resume and the job posting, and it rewrites the resume for that specific job, counts how many of the posting’s skills your resume actually carries, separates the ones you could surface from the ones you would genuinely have to build, and adds three recruiter notes on what would make someone hesitate. It needs a free account.
Sources
Every claim above came from one of these. All were read directly, not summarized from secondary coverage.
- Greenhouse Support, Search candidates using Boolean queries: https://support.greenhouse.io/hc/en-us/articles/202360199-Search-candidates-using-Boolean-queries
- Workday, Concept: Candidate Skills Match, administrator documentation: https://doc.workday.com/admin-guide/en-us/human-capital-management/recruiting/candidates/candidate-skills-match/bmj1604095304483.html
- Workday Engineering, Skill Inference: Building an LLM-based Service in the Workday Skills Cloud, 2025: https://medium.com/workday-engineering/skill-inference-building-an-llm-based-service-in-the-workday-skills-cloud-47c9cce9f7bd
- LinkedIn Engineering, The AI Behind LinkedIn Recruiter Search and Recommendation Systems, 2019: https://www.linkedin.com/blog/engineering/recommendations/ai-behind-linkedin-recruiter-search-and-recommendation-systems
- LinkedIn Engineering, Semantic Search for AI Agents at Scale, 2026: https://www.linkedin.com/blog/engineering/ai/semantic-search-for-ai-agents-at-scale-retrieval-and-ranking-for-linkedins-hiring-assistant
- LinkedIn Engineering, Reimagining LinkedIn’s search tech stack, 2026: https://www.linkedin.com/blog/engineering/search/reimagining-linkedins-search-stack
- Our own layer-1 abbreviation experiment, 2026-08-18. Eighty-four combinations of wording, search style and engine setting, covering quoted and boolean searches with word stemming on and off. Internal; the two results it supports are the both-forms credential finding and the label-plus-evidence sentence shape, both stated in the text above as things we tested rather than things a vendor documents.
