AI CV screening works well in English. The models were trained on English resumes, the benchmarks are English, and the vendors demo in English.
Turkish is where it gets interesting — and where a tool that scored well in a demo can quietly return half the candidates it should. The failures are not loud. Nothing errors. You simply see fewer matches and assume the pipeline is thin.
Here is what actually breaks, and how to check for it with your own data.
Agglutination: one word where English uses four
Turkish builds meaning by attaching suffixes to a root, so a single word can carry what English spreads across a phrase.
A job title on a CV might appear as yazılım geliştirici, yazılım geliştiricisi, yazılım geliştiricilerinden, or yazılım geliştiriciliği depending on the sentence around it. All four refer to the same role. A system matching on exact strings, or on a keyword list built from English-language assumptions, will catch some and miss the rest.
This matters most for boolean or keyword-based filters, which is still how a lot of screening works underneath a modern-looking interface. Semantic matching handles it better, but only if the embedding model has meaningful Turkish coverage — many are overwhelmingly English-weighted, and their Turkish behaviour is noticeably weaker than their English behaviour rather than merely a little weaker.
How to test it: take one real CV, and search for its job title in three inflected forms. If only the exact form returns the candidate, the system is matching strings, not meaning.
The dotted-i problem
This one is specific, mechanical, and extremely common.
Turkish has two distinct letters where English has one: i (dotted) and ı (dotless). Their uppercase forms are İ and I respectively. That is the opposite of the English rule, where uppercase "I" lowercases to "i".
Any system that normalises text using invariant or English casing rules will turn İSTANBUL into i̇stanbul or ISTANBUL into istanbul incorrectly, and the normalised form will no longer match what is in the database. The candidate is in your system. The search does not find them.
The same applies to names — Işıl, İlker — and to any filter on city, university or company name.
How to test it: search for a candidate whose city or name contains İ or ı, typing it in a different case than it is stored. If the result disappears, the casing is being handled with the wrong locale.
Local CV conventions the model has never seen
Turkish CVs carry fields that do not appear in the English-language training data at all.
Military service status (askerlik durumu) is a standard field for male candidates — completed, deferred, exempt. Systems that do not know it either drop it or classify it as something else.
Education naming. A Turkish CV may name a high school in a way that carries real signal locally — the Anadolu and Fen Lisesi system, for example — and none at all to a model trained elsewhere. The same is true of university names: the distinction that a local recruiter reads instantly from "Boğaziçi" or "ODTÜ" is invisible to a system with no local prior.
Date and format conventions. Turkish CVs commonly use DD.MM.YYYY. A parser expecting MM/DD/YYYY will either fail or, worse, succeed incorrectly and record the wrong dates for every candidate whose day is twelve or lower.
Mixed-language CVs. Senior technical candidates frequently write in a mix: Turkish prose with English technical terms, or an English CV with Turkish institution names. A pipeline that detects one language per document and processes accordingly will mishandle the other half of every such CV.
How to evaluate a tool properly
Vendor demos are run on CVs chosen to work. Replace them with yours.
Assemble a real sample. Thirty to fifty CVs from a position you have actually filled. Include the mixed-language ones and the badly formatted ones — those are the realistic case, not an unfair test.
Label them yourself first. Have someone on your team rank the sample before the tool sees it. Without this you have nothing to compare against, and you will end up evaluating whether the output looks plausible, which it always does.
Measure misses, not hits. Any tool can return plausible top candidates. What tells you whether it works is who it left out. Take the candidates your team ranked highly and check where the tool placed them. Candidates who were strong and got buried are the real signal.
Test the searches you will actually run. Inflected job titles, Turkish characters in a different case, a city name, a university. Five minutes of this reveals more than an hour of demo.
Ask what happens to CVs it cannot parse. Every parser fails on some documents. The question is whether those candidates are flagged for a human or silently dropped. Silently dropped is a bad answer, and a surprisingly common one.
The part nobody sells
The largest gains in screening usually do not come from a better model. They come from having the data in one place, in a consistent structure, with the failures visible.
A screening tool with mediocre Turkish handling but an honest "12 CVs could not be parsed, review them" is more useful than one with an excellent score and a silent 12. The second one looks better and costs you twelve candidates every time.
When comparing tools, weight that behaviour as heavily as accuracy. Accuracy you can measure in a pilot; silent failure you discover months later, if at all.