Back 
Artificial intelligence is changing how people work, and recruitment is no exception. For decades, job boards and applicant tracking systems (ATS) have helped organisations manage vacancies and applications. They store and organise massive amounts of information, but one thing has barely changed: the way people actually search for jobs.
Most platforms still rely on keyword matching. Candidates are expected to guess the exact words a recruiter used in a job description, while recruiters hope applicants search using those same terms. That rarely happens in practice.
We built a different kind of job search: one that understands what candidates mean, not just what they type. Behind the scenes, several components work together, each solving a different problem. When combined, they make search feel much more natural. Below, I’ll explain why the old way struggles, how we built the search pipeline, and what it looks like under the hood.
Problem statement
The classic job-search flow is simple: land on a job board, type a title/keyword into a search bar, and hope the results match what you want. Traditional search compares your search terms with the words stored in its database. If the keywords match, the vacancy appears; if they don’t, it doesn’t.
That works until you realise people don’t use the same words. A company might list a role as Chauffeur while candidates search for Driver. A Customer Success Manager might be labelled Client Relationship Manager.
During testing, we saw this happen surprisingly often, especially for fast changing roles. Two companies can advertise almost identical roles using completely different titles. That made it obvious that relying purely on keyword matching wasn’t going to scale. A “Platform Engineer” at one company might be doing pure backend work, while someone else calls it a “Backend Developer.” Traditional search treats those phrases as entirely separate, even though any engineer looking at it recognises the overlap.
The result is simple. Candidates miss jobs they’d actually be a good fit for, and recruiters miss people who could have been shortlisted.
From keywords to intent
Instead of asking “Does this job contain these exact words?”, our system asks “What is the user trying to find?”
A search for “sales representative” should automatically surface roles such as Marketing officer, Business Development Executive, Account Manager, or Field Sales Consultant. By bridging these language gaps automatically, users can search naturally instead of trying different keyword combinations to guess what the recruiter wrote.
Breaking down the search pipeline
At a high level, the flow is straightforward. A user’s search first passes through the Natural Language Search and LLM layers, where we extract intent and build structured search filters. That information is then combined with Semantic Search to find the most relevant jobs from the indexed ATS data before the results are ranked and returned.
Natural Language Search
Users can type what they want. For example: “Looking for a remote Marketing role, around five years’ experience in London.” The system parses that sentence and converts the user’s query into structured search filters extracting the remote flag, the specific tech stack, the experience level, and the location. It feels more like talking to a person than searching a database.
Semantic Search
We initially tried simpler approaches like synonym expansion and keyword boosting, but they quickly became difficult to maintain as more job titles and technologies were added. Semantic search proved much easier to scale because it understands the overall meaning rather than relying on manually maintained keyword lists.
Both job descriptions and search queries are converted into vectors. The semantic engine compares these vectors to understand how closely related two pieces of text are, even if they don’t use the same words. This means a job described as “UI engineer” automatically ranks highly for someone searching “frontend developer.”
LLM Query Understanding
We added an LLM-based layer to clean up the user’s input before it hits the semantic engine. It helps work out what vague phrases mean, normalises abbreviations, and extracts core intent. If someone types “HR”, it resolves to Human Resources. If they type “Mgr”, it expands to Manager. It’s a smart pre-processing step that ensures the pipeline receives clean, standardised data.
ATS Integration
We do not replace an organisation’s ATS. The search layer connects to it through standard APIs and webhooks, pulling in job descriptions and metadata while the ATS continues to handle the actual hiring workflows. Teams keep their history and processes; they just get a much better search experience. We typically start with a one-time full index, followed by streaming updates so new roles appear almost immediately.
The limitations of AI
AI is a tool, not an human replacement. Poorly written job descriptions, incomplete metadata, or stale data will still give you bad results. That’s why we focused heavily on improving existing recruiter workflows rather than trying to replace human decisions.
- We prioritise transparency. We are using AI, does not mean we are loosing control. If a result matched to a particular keyword then there is clear mapping to explain “why”.
- We run strict data quality checks before indexing to ensure the text is clean and don’t hold any PII.
Data privacy and compliance
When it comes to privacy, candidate data is heavily restricted. Integrations only index the public-facing parts of job postings and no ATS metadata or PII. Candidate profiles and applications remain fully under ATS control, we don’t query or see them. We ensure organisations can meet regional privacy requirements like GDPR. The search layer is used purely for search and matching, not unrelated profiling or analytics.
Migration and adoption
You don’t need to years of RND and huge investment to get smarter search. Because the platform is built to sit alongside existing ATS installations, the migration path is straightforward. We connect the API to stream job updates, run your initial sync, and gradually turn on the natural language features while monitoring your relevance metrics to make sure the results are actually improving. The best part is if a ranking behaviour needs adjustment, the components can easily be tuned.
Putting the pieces together
To see how this operates in practice, consider what happens when candidate intent meets the system. If a hiring team posts a “Business Development Executive” role, traditional keyword searches may miss candidates searching for “Sales Representative” or “Sales Executive” jobs, even though they’re looking for very similar opportunities.
With the new pipeline, semantic indexing maps the job description to a related vector. When a candidate searches naturally for a role, the LLM catches the intent and the semantic ranker finds the match. The system bridges the gap between what the company called the job and what the candidate searched for, surfacing relevant hits regardless of formatting or shorthand. From the user’s perspective, it simply feels like the search understood what they meant.
What to expect
This implementation improves how candidates find jobs by focusing on meaning, not keywords. Expect fewer missed matches, better-ranked results, and less manual fiddling with search terms.
Conclusion
Our goal is simple: make job search work the way people naturally search. By combining Natural Language Search, Semantic Search, LLM Query Understanding, and existing ATS data, we’ve been able to make job search feel much more natural for candidates while helping recruiters discover better matches, all without disrupting the systems they already rely on.
