Boolean searches and building candidate pools

The annotated Boolean — the only Boolean prompt worth using

The naive prompt — “Give me a Boolean search for a backend engineer in Kathmandu” — produces a syntactically valid string that you have no way to adjust. You run it, get 800 results, want to narrow to mid-level, and have to re-prompt. You want to exclude managers, and have to re-prompt. You want to add Pokhara, and have to re-prompt. Each round is a new conversation; the model has no memory of why it included what it included, and you have no way to tell which clause is doing what work.

The pattern that works is annotated Boolean prompting. You ask the model not just for the string but for a brief one-line explanation of each clause. Now you can read the string, understand which clause is doing the filtering you want and which is filtering out candidates you would have taken, and adjust it yourself — without going back to the model.

The prompt looks like this:

Generate a LinkedIn X-Ray Boolean search for a mid-level backend engineer based in Nepal.

Must-haves: 3–6 years of backend experience, comfort with at least one of Go, Java, or Python, currently based in Nepal (any city, not just Kathmandu). Nice-to-haves: payments domain, microservices, AWS or GCP. Exclude: anyone with “manager”, “director”, “head of”, or “VP” in their current title. Exclude obvious students and interns. Synonyms to consider: “backend engineer”, “backend developer”, “server-side engineer”, “platform engineer”.

Output format: 1. The full Boolean string. 2. A bullet list explaining each clause — what it includes, what it excludes, and a guess at how restrictive the clause is. 3. Two alternative strings — one looser (more results, less precise), one tighter (fewer results, more precise).

The output is genuinely useful. You can see that the clause ("backend" OR "server-side") is doing most of the work, that the -"intern" exclusion is cheap, and that adding ("Nepal" OR "Kathmandu" OR "Lalitpur" OR "Pokhara") would narrow more sharply than just "Nepal". You adjust by deleting or changing clauses in the string itself, not by reopening the chat. After three or four roles you stop using the model to generate Booleans and start using it only to add synonyms you have not thought of.

The pool you build over time

Most recruiters in Nepal do not have a candidate pool. They have a folder of CVs from the last role they closed, and a vague memory of “that good frontend developer I talked to in February”. When the next role opens, they start from scratch — same job board posts, same LinkedIn search, same fifty people.

A real pool is different. It is a single searchable record — a spreadsheet, an ATS, even a well-tagged Notion database — where every interesting candidate you have ever encountered is captured with:

• Role (backend, frontend, finance, programme manager, etc.)
• Level (junior, mid, senior, lead, head)
• Location (Kathmandu Valley, other Nepal city, diaspora, returnee diaspora)
• Channel (where you found them — LinkedIn, Facebook, referral, conference, university)
• Status (open to roles, passive, “not for two years”, “do not contact”)
• Last touch (date and channel)
• The one specific thing you noticed (the talk, the post, the project, the recommendation)

The last field is the one most pools miss. Without it, six months later, you cannot remember why you flagged the candidate — and the next outreach is generic again.

AI helps with the systematisation, not the substance. You can ask the model: “Here are 20 candidate notes I took over the last quarter. Pull out for each: name, role, level, location guess, status, and the one specific thing I noticed. Format as a CSV I can paste into my pool.” The model is excellent at this kind of structural extraction. What it cannot do is meet the candidate; that part is still you.

Over a year, a sourcing-focused recruiter who maintains a real pool will accumulate 300–500 tagged candidates. The third or fourth time you open a similar role, the first hour of sourcing is searching the pool, not searching LinkedIn. The reply rates on outreach to “we spoke briefly six months ago” candidates are dramatically higher than to cold candidates. The pool compounds.

The Nepali sourcing reality AI cannot bypass

It is tempting to treat sourcing as a Boolean problem the model can solve. In Nepal, it is not. The Boolean string only searches the candidates who have already put themselves on the channel you are searching. That coverage is wildly uneven.

LinkedIn coverage is partial outside Kathmandu Valley. A senior backend engineer in Itahari, Butwal, or Dhangadi is much less likely to maintain an active LinkedIn profile than one in Kathmandu. Boolean searches that look only at LinkedIn quietly exclude the entire eastern and far-western talent base. The work is to know which channels reach those candidates — local Facebook professional groups, regional university alumni networks, college career placement offices in Biratnagar and Pokhara — and to use AI to describe and search those channels rather than to substitute for knowing they exist.

Facebook groups carry much of the SME, mid-career, and provincial talent. Nepali Accountants Forum, HR Nepal, various district-level professional groups, women-only professional groups — these are not on any X-Ray search. You join, observe the norms, post or DM. AI helps you write the post and adapt the tone; it does not help you find the group.

Professional WhatsApp and Viber groups are even more closed. Entry is by referral. The strongest mid-level CA and ACCA candidates in Nepal coordinate hiring conversations in WhatsApp groups that no recruiter who is not already known will ever join.

Diaspora and returnee talent — Nepalis working in Bangalore, Dubai, Australia, US, UK who would consider returning — are a real and growing pool, but they are scattered across diaspora Facebook groups, NRN networks, alumni Slack channels, and Twitter/X. Their LinkedIn profiles often list their current foreign employer, so a Nepal-based Boolean misses them entirely. The work is to search by university and prior employer, not by current location.

Women-only professional networks — Women Leaders in Technology, Women in IT Nepal, Women in Tourism, various WhatsApp groups — exist specifically because the general channels under-source women. If a recruiter searches only LinkedIn and only general groups, the resulting candidate slate will skew male by default. The fix is not to ask the model to “find more women” (it cannot, and the request is ethically dubious) but to know the women-only channels exist and to source on them directly.

Avoiding the “same fifty people in Kathmandu” trap

The single largest pattern failure in Nepali sourcing is geographic and demographic concentration — slate after slate of the same Kathmandu Valley engineers from the same five companies, the same Lazimpat finance professionals, the same INGO programme officers who moved between three organisations over five years. The pool feels exhausted because the search is structurally narrow.

The discipline is to make every Boolean and every pool explicitly include the missing categories. The prompt instruction is one line: “In addition to the standard search, generate three additional Boolean strings: one targeting candidates outside Kathmandu Valley (Pokhara, Biratnagar, Butwal, Dharan, Itahari, Birgunj, Nepalgunj, Dhangadi), one targeting returnee diaspora (Nepali professionals currently in India, Gulf, Australia, US, or UK with university education in Nepal), and one targeting women-specific professional networks and alumni groups.” The model generates four strings instead of one. You run all four. The candidate slate doubles in size and triples in diversity. The first interview round changes character entirely.

This is not a “diversity initiative” framing. It is a sourcing-quality framing. Slates drawn from a wider geographic and demographic pool reliably produce better hires because the pool itself is larger. The “same fifty people” pool, repeatedly tapped, fills positions but does not fill them with the best available candidate — only the most convenient one.

What never goes into a public chatbot

The same rules from earlier sections apply. Do not paste candidate names, employers, contact details, or any identifying information into a public chatbot when generating Boolean strings or organising pools. Use role descriptors. When extracting structured data from candidate notes you took, redact identifiers before pasting, or use an enterprise account with a no-training agreement. The CSV the model gives you back can have placeholder names; you fill in the real names locally.

Check your understanding

Quick check

—

A sourcer asks AI to generate a LinkedIn Boolean string for a mid-level backend engineer in Nepal. Which prompt instruction will produce the most useful output — the one the sourcer can adjust without re-asking the model?

1. AGive me the most optimised Boolean string possible.
2. BGenerate a Boolean string with each clause briefly explained — what it includes, what it excludes, and how restrictive it is — plus two alternative strings, one looser and one tighter.
3. CGenerate a Boolean string and tell me how many results it will return.
4. DGenerate the shortest possible Boolean string.

Check answer→

What comes next

A well-built pool and well-targeted outreach will produce CVs — many more CVs than a hiring manager can read carefully. The next chapter is about screening: how to use AI to triage applications honestly without inheriting the bias that lives in any pattern-matching system, and the specific cases where AI screening will systematically penalise candidates whose CVs do not match the dominant template — non-tier-1 universities, women returning from a career break, candidates whose career took an unusual route. The screening chapter is where the stakes of using AI carelessly become highest.