A blank job-title field doesn’t necessarily mean an unrestricted search. In a job-search application I’ve been developing, a search with no manually entered titles could use suggestions drawn from the user’s resume. Those suggestions narrowed the search before the AI model scored the postings, so a missing job could be a filter decision the user hadn’t seen.
A fictional example: a candidate’s resume supports both data architecture and enterprise architecture, but the suggested filter contains only “Enterprise Architect”. The collector finds a “Data Architect” posting, and the title check rejects it. The candidate might be well qualified for the work; the scoring model never gets to consider that question.
Changing the scoring prompt won’t bring that posting back. Neither will asking the model to explain its rankings more carefully, since the missing posting isn’t among the things it’s ranking. The explanation can be perfectly reasonable and still tell us nothing about the earlier exclusion.
There are two questions to answer: did we collect a useful range of postings, and did we rank that range well? We can inspect the returned scores and decide that their order makes sense, but that doesn’t tell us what the search left out. An orderly shortlist is easy to mistake for a complete one (especially when you’re tired of looking for work).
I worked on broadening the resume-derived role suggestions and making the effective filter visible. The useful explanation starts before the score: these were the titles used, and they came from your resume rather than something you typed. A blank field shouldn’t leave the user guessing which restrictions the application supplied on their behalf.
Broadening takes some care. “Enterprise Data Architect” can be searched under the broader “Data Architect” family, but “Enterprise Architect” and “Data Architect” aren’t interchangeable just because they share a word. A resume that supports both should retain both. Adjacent roles need evidence in the described responsibilities; an AI keyword doesn’t establish management experience, and an empty suggestion slot isn’t a qualification.
The rejection explanation matters too. “This posting’s title didn’t match the role filter” gives the user a different problem to solve from “this posting received a low match score”. If location eligibility couldn’t be established, say that instead. A small record of the title, stage and reason can explain an exclusion without copying the resume or the full posting into a general maintenance log.
The implementation gives us more information about those decisions; it doesn’t establish that users receive better matches. To test that, I’d use synthetic resumes and a reviewed set of postings, including relevant jobs that ought to survive the filters and unsuitable ones that ought to be excluded. I’d check where each posting went before judging the final ranking. More results alone wouldn’t settle it.
Before rewriting the scoring prompt, pick one relevant posting that should have appeared and follow it through the search. Was it found? Did it pass the filters? Was it scored? Change the decision that excluded it.
—jhunterj