Build Boolean search strings for a [TARGET ROLE] search in [LOCATION OR WORK ARRANGEMENT]. The hiring requirements are: [MUST-HAVES]. Preferred but nonessential qualifications are: [PREFERENCES]. My approved sourcing policy and limits are: [POLICY AND PLATFORM]. Known titles, tools, employers, or domain terms to include or avoid are: [SEARCH CONTEXT]. Start by separating true minimum requirements from preferences. Translate each requirement into likely titles, adjacent titles, common abbreviations, tool names, and domain synonyms. Treat titles as imperfect signals, not proof of qualification. Do not use or infer protected characteristics, proxies for them, age, graduation year, gendered terms, nationality, religion, disability, family status, or other criteria prohibited by [POLICY AND PLATFORM]. Do not create exclusion terms that could unlawfully narrow the pool. Return: 1. A plain-English search logic map with required concept groups, optional groups, and terms intentionally excluded. 2. One broad discovery string, one balanced string, and one narrow high-signal string, each in a code block and labeled for [POLICY AND PLATFORM]. 3. A title-synonym list and a separate skill-synonym list. 4. A short test plan: which terms to remove first if results are too small, and which precision terms to add if results are too broad. 5. A recruiter screening reminder listing what must be verified from a profile or interview rather than assumed from the query. Use correct parentheses, quotation marks, AND, OR, NOT, and platform syntax. If [POLICY AND PLATFORM] does not permit NOT, replace exclusions with an allowed refinement approach. Before answering, check parentheses and operator logic for errors. Also check that every mandatory term traces back to [MUST-HAVES], and flag policy ambiguity rather than guessing. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TARGET ROLE] | Enter the role you are sourcing for. | Senior Data Analyst |
| [LOCATION OR WORK ARRANGEMENT] | State the location, time-zone, remote, hybrid, or onsite requirement. | US remote; overlap with Eastern Time business hours |
| [MUST-HAVES] | List the genuinely required skills, experience, licenses, or work authorization criteria approved for the role. | Three or more years analyzing product or customer data; advanced SQL; dashboard experience; authorization to work in the US. |
| [PREFERENCES] | List useful but nonessential qualifications. | Python, Looker, subscription SaaS, experimentation experience. |
| [POLICY AND PLATFORM] | Name the search platform and paste relevant company policy, legal, or platform constraints. | LinkedIn Recruiter. Follow company equal-employment policy; do not use protected-trait filters or school-graduation filters. |
| [SEARCH CONTEXT] | Provide approved title, tool, industry, employer, or exclusion context. | Include titles Data Analyst, Product Analyst, Business Intelligence Analyst. Include SQL, Tableau, Looker, Power BI. Do not require specific employers. |
How to use
- Turn the approved job brief into must-haves and preferences before generating a query.
- Paste the platform name because Boolean operators and field syntax differ across tools.
- Run the broad string first and inspect several results before narrowing it.
- Follow up with: “Results are too broad because of generic BI titles; propose two compliant precision changes and explain the tradeoff.”
Variations
LinkedIn X-ray
Use this when searching public LinkedIn profiles through a web search engine.
Create a Google X-ray Boolean query for public LinkedIn profiles of [TARGET ROLE] candidates in [LOCATION]. Requirements: [MUST-HAVES]. Approved optional signals: [PREFERENCES]. Policy constraints: [POLICY]. Return a broad and narrow query using site:linkedin.com/in/ and valid Google syntax, plus a short explanation of each concept group. Do not use protected-trait terms, graduation dates, or discriminatory proxies. Check parentheses, quotes, and that every hard requirement comes from the approved brief.
Talent pool map
Use this before writing a query for an unfamiliar role.
Map the sourcing vocabulary for [TARGET ROLE] in [INDUSTRY]. Hiring brief: [REQUIREMENTS]. Return related job titles grouped by likely seniority, software or methods that demonstrate the core work, adjacent backgrounds, and misleading titles to review manually. Mark each item as must-have evidence, useful signal, or weak proxy. Do not infer protected traits or recommend exclusion criteria based on personal characteristics. Flag assumptions that require the hiring manager’s approval.
Search calibration
Use this after a first Boolean search returns the wrong candidates.
Diagnose this Boolean query: [CURRENT STRING]. I need [TARGET ROLE] candidates with [MUST-HAVES], but current results are [RESULT PROBLEM]. Platform and policy rules: [PLATFORM POLICY]. Explain the logic issue, then provide two corrected strings and expected tradeoffs. Preserve fair-search limits; do not add protected-trait terms or unapproved hard filters. Check operator precedence and identify any term that is too broad or ambiguous.
Tips
- Define minimum qualifications with the hiring manager before writing syntax; a Boolean string cannot repair an unclear brief.
- Keep domain terms in optional groups when the work can be done in several industries, then assess context during screening.
- Test title alternatives separately when results are thin, because titles often vary more than skill language.
- Document why each hard filter is job-related so the query can be reviewed and reused consistently.
FAQ
Should I put every preferred skill in a Boolean string?
Usually no. Long AND chains reduce qualified results quickly; use preferences to rank or refine after you see the pool.
Can Boolean search prove a candidate is qualified?
No. It finds profiles with potential signals. Verify scope, recency, results, and required qualifications in the profile and interview.
Is NOT always useful?
No. It can remove relevant people with mixed backgrounds or broad profiles. Use it only for a clearly irrelevant term and only where policy and platform rules allow it.