Keyword or semantic search?

Keyword search fails when the same idea is expressed differently — "ETL" and "data pipelines", "SDR" and "sales development". It returns nothing and the user concludes there are no such jobs.

Semantic search fails on exact tokens: a specific certification name, a version number, an uncommon product, an acronym it has not learned. It returns things that are broadly about the right area and miss the precise thing the user typed.

Note which failure is visible. Keyword search returning nothing tells the user something went wrong; semantic search returning ten plausible-looking results that all lack the required clearance tells them nothing at all, which is why the quieter failure deserves more attention.

For rare, precise terms, lexical matching is not merely adequate — it is correct. Someone searching for an exact framework, a clearance level or a named qualification wants documents containing that token, not documents that are conceptually adjacent.

It is also instant, cheap, and completely explainable: you can point at why a result matched. Those properties matter more in production than they do in benchmarks.

Weighting the section a term matched in extends that advantage considerably. A phrase in the job title should outrank the same phrase buried in a company history paragraph, and a lexical index treating every part of the document equally produces results a user reads as obviously wrong.

Where it wins is when the user does not know the vocabulary the postings use. "Jobs where I help customers succeed technically" has no literal match and a clear meaning, and only an embedding-based approach connects it to solutions engineering roles.

This is also the case for CV-to-job matching, where the candidate never chose their words with a search engine in mind.

Job titles are the strongest everyday case. The same work is advertised as platform engineer, infrastructure engineer, SRE and DevOps engineer depending on who wrote the posting, and only meaning-based retrieval reaches all four from one query.

Run both and combine the rankings. The standard approach is reciprocal rank fusion, which merges result lists without needing the two scores to be on a comparable scale — a detail that matters, because lexical and vector scores are not comparable and naive weighted averaging quietly favours whichever produces larger numbers.

Then re-rank the merged top results with a cross-encoder or a model if quality justifies the cost. This is the architecture behind most search that feels good.

Apply the hard filters inside retrieval rather than after it. Country, eligibility and whether a posting is still open are not signals to weigh, and filtering a fused top hundred afterwards leaves a handful because most of them were somewhere else.

• Lexical retrieval for exact and rare terms
• Vector retrieval for intent and paraphrase
• Rank fusion rather than score averaging
• Optional re-ranking of the merged shortlist

It is worth being honest that employer-side screening is further behind than search. A great deal of it is still lexical, which is why a CV that describes work perfectly in the candidate’s own vocabulary can fail a filter it deserved to pass.

That is changing unevenly rather than uniformly, so the safe assumption is that both methods are in play and neither can be relied on alone. Writing for only one is a bet on which system this particular employer happens to run.

The practical consequence is asymmetric. Including a literal term costs a few words and occasionally saves an application; omitting it costs nothing until it costs the screen, which makes it insurance rather than optimisation.

Since screening systems increasingly run both, write for both. Use the natural language that describes your work properly — semantic matching rewards it — and also include the literal terms a posting would use, because lexical matching only finds what is there.

That is not keyword stuffing. It is writing "built and operated ETL pipelines" rather than choosing between the plain description and the jargon.

The line is whether the term is true. A literal word added to a sentence describing work you did is accurate and matchable; a term added because a posting asked for it is a claim you will be asked about in the first technical conversation.