Sourcing Plan & Boolean Search Strings
Builds on Topic 5.
What you'll produce
A sourcing plan for your open Senior Backend Engineer req: the ideal-candidate profile translated into concrete search criteria, the channels you'll work and why, 3–4 tested Boolean search strings (with AND / OR / NOT) plus the filters you'd layer on each, and a simple capacity plan for how many people you'll touch to fill the role. This is the document that turns the intake's must-haves (Deliverable 1) into a repeatable hunt for passive candidates — the people who aren't applying but are exactly who you need. It matters because sourcing is the engine of technical recruiting: in a tight, expensive market like senior backend/payments, the candidates who answer your job post are rarely your best hires, and a recruiter who can write a precise Boolean string and pick the right pond is worth far more than one who only screens inbound. This is also the single most common live exercise in tech-recruiter interviews ("here's a role — source it"), so the artifact doubles as proof you can do the job on a whiteboard.
Instructions
- Pull the must-haves from your intake brief. Open Deliverable 1 and copy the true must-haves and the salary/location/remote/seniority logistics. Everything below sources against these, not against Dana's original wish-list. If a "requirement" wasn't a real must-have, do not let it narrow your search.
- Translate the profile into search criteria. For each must-have, write the concrete signals you'd actually search for: languages (Python, Go), domain keywords (payments, ledger, transactions, PCI), scale/system signals (distributed systems, high-throughput, microservices, Kafka), seniority signals (years, "Senior"/"Staff" titles, tech-lead language), and current/target companies. Separate keyword signals (go in the Boolean string) from filter signals (location, years of experience, set in the platform's filters).
- Choose your channels and justify each. List 4–5 channels (e.g., LinkedIn Recruiter, GitHub, internal referrals, niche communities, your ATS/silver-medalists) and write one line on why this channel fits this profile and what you expect from each. Don't list channels you won't actually work.
- Write 3–4 Boolean strings, each with a clear intent. Make each string target a different angle (e.g., one broad-net, one payments-specialist, one Go-heavy distributed-systems, one competitor/title-based). Use AND to require, OR to widen synonyms, NOT to exclude noise, quotes for exact phrases, and parentheses to group. Label what each string is for.
- Attach filters to each string. Under each Boolean, list the platform filters you'd set: location/remote radius, years of experience, current-company include/exclude lists, "open to work" / activity signals, and anything you deliberately leave off to avoid over-filtering (e.g., do NOT require a degree).
- Plan capacity and sequencing. Estimate how many qualified profiles each channel yields and, working back from your funnel, how many people you need to contact to hit ~2–3 finalists. State which string/channel you'll run first and why.
- Add a bias-and-noise check. Note 1–2 ways your strings could unfairly narrow the pool (e.g., excluding career-gappers, non-traditional titles, or under-indexing women/underrepresented engineers who self-describe differently) and how you'll widen to compensate. Sourcing fairly is a job-relevant skill, not a nice-to-have.
Worked example
(Role: Senior Backend Engineer — Northwind, Series B payments-infra fintech, NYC. Pulled from the Deliverable 1 intake with Dana, VP Eng.)
Must-haves carried from intake: (1) Strong backend in Python or Go (either is fine — Dana confirmed it's not both); (2) Distributed-systems experience at real scale (not a solo-CRUD background); (3) Has worked on money-movement / high-integrity data — payments, ledgers, billing, banking, exchange, or comparable correctness-critical systems; (4) Senior level — ~6+ years, can own a service end-to-end and mentor. Logistics: $185–215K base + equity; hybrid — 2 days/week in NYC, ~50-mile radius — or strong remote in US Eastern/Central time; target signed offer in 8 weeks. (This is the exact policy from the Deliverable 1 intake; sourcing against a fuzzier version of it — "3 days," "a bit of travel," no radius — is how candidates self-select out at offer stage, so it stays word-for-word identical here.) Explicit non-must-haves Dana dropped at intake: CS degree, prior fintech brand names, and "10+ years" — these became nice-to-haves so they will not narrow the search.
Ideal-candidate profile → search criteria
| Must-have | Keyword signals (go in Boolean) | Filter signals (set in platform) |
|---|---|---|
| Python or Go backend | Python, Golang, "Go", backend, "back-end", "server-side", microservices, API | — |
| Distributed systems at scale | "distributed systems", Kafka, Kubernetes, "high throughput", "high-scale", gRPC, "event-driven", concurrency | — |
| Money-movement / high-integrity data | payments, ledger, "double-entry", billing, transactions, fintech, banking, PCI, "money movement", reconciliation | Current/past company list (see below) |
| Senior, ~6+ yrs, owns a service | Senior, Staff, "Tech Lead", "backend lead" | Years of experience: 6–15; Seniority filter: Senior/Staff |
| Location / comp | — | 2 days/week in NYC, ~50-mile radius (NYC metro within 50 mi) OR US-remote (ET/CT); exclude profiles flagged outside band where visible |
Channels (and why each fits this profile)
- LinkedIn Recruiter — primary. Where senior backend engineers are findable and filterable by company, tenure, and skills; carries ~70% of the load for this search. Expect the bulk of my outreach pipeline here.
- GitHub — secondary, high-signal. Backend/distributed-systems engineers leave a public trail. Searching by language + location surfaces people who are invisible or passive on LinkedIn and lets me see real code/projects. Lower volume, higher conviction.
- Referrals — highest quality, run day one. Northwind already has ~12 engineers; I'll ask Dana and the two staff engineers for 2–3 names each ("who's the best backend engineer you've worked with who's touched payments?"). Referrals convert far better and cost nothing.
- ATS silver-medalists + my network. Northwind has been open a month; I'll mine prior strong-but-not-hired backend candidates and re-engage. Fastest possible win if one exists.
- Niche communities — supplementary. Payments/distributed-systems engineers cluster in places like the Rands Leadership and Gergely Orosz / "Pragmatic Engineer" communities and conference attendee lists (QCon, KubeCon). Used for warm context and a few targeted names, not bulk.
Boolean strings (tested, with intent and filters)
String 1 — Broad net (Python or Go backend at scale). Catches the widest qualified pool before I specialize.
("software engineer" OR "backend engineer" OR "back-end" OR "server-side" OR "software developer")
AND (Python OR Golang OR "Go")
AND ("distributed systems" OR microservices OR "high throughput" OR Kafka OR Kubernetes)
AND (Senior OR Staff OR "Tech Lead")
NOT (intern OR "front-end" OR "frontend only" OR student OR recruiter OR "looking for")
Filters: Location = 2 days/week in NYC, ~50-mile radius (NYC Metro, 50 mi) + US-remote in ET/CT only (don't set a bare "Remote — United States" — it floods you with PT-coast profiles who can't do the office days and aren't in the intake's timezone band); Years of experience = 6–15; Years in current role = 1+ (skip brand-new hires); exclude current company = Northwind. Deliberately NOT set: degree, specific top-tier companies (would over-filter).
String 2 — Payments / money-movement specialist. Narrows String 1's pool to the domain Dana cares most about.
(Python OR Golang) AND (backend OR "server-side" OR microservices)
AND (payments OR ledger OR "double-entry" OR billing OR transactions OR fintech OR banking OR PCI OR reconciliation OR "money movement")
AND (Senior OR Staff)
NOT (sales OR "account executive" OR support OR QA OR intern)
Filters: Same location/remote and 6–15 yrs as String 1; Include current-or-past companies = Stripe, Plaid, Adyen, Block/Square, Brex, Ramp, Modern Treasury, Marqeta, Mercury, Goldman/Marcus, Capital One, plus crypto-exchange names (Coinbase, Gemini). This is where my best 1-in-3 profiles will come from.
String 3 — Go-heavy distributed systems (correctness-critical, even if not labeled "fintech"). Widens the pool to engineers with the right systems instincts from adjacent high-integrity domains (exchanges, infra, ad-tech billing) who never used the word "payments."
(Golang OR "Go developer" OR "Go engineer")
AND ("distributed systems" OR "event-driven" OR gRPC OR "consensus" OR Kafka OR "exactly-once" OR idempoten*)
AND (Senior OR Staff OR Principal OR "Tech Lead")
NOT (frontend OR designer OR "data entry" OR student)
Filters: Location/remote as above; Years 6–15; this string runs mostly on GitHub too (search: language:Go location:"New York" followers:>20 and inspect repos for queues/ledgers/payment libs).
String 4 — Competitor / title-based fast lane. A short, high-precision string to pull obvious near-matches quickly while I refine the rest.
("Senior Software Engineer" OR "Staff Software Engineer" OR "Senior Backend Engineer")
AND (Python OR Go)
AND (Stripe OR Plaid OR "Modern Treasury" OR Adyen OR Marqeta OR Brex OR Ramp OR Mercury OR Square OR Block)
NOT (manager OR director OR "looking for a recruiter")
Filters: Location/remote as above; "Open to work" signal = on (prioritize, don't require); sort by recent activity.
Capacity & sequencing. Working back from the funnel in my intake (roughly: contact 60 → 20 reply → 10 screen → 4 submit → 2–3 onsite → 1 offer), I need to contact ~55–65 qualified passive candidates over the first 3 weeks to land 2–3 finalists in an 8-week window. Sequencing: Week 1 — referrals + ATS silver-medalists + run String 4 (fast wins), and send String 2 (the money-makers) for ~20 contacts. Week 2 — work String 2 to exhaustion and layer String 3 on GitHub. String 1 is my fallback/top-up if reply rates run low. I'll review the first ~6 profiles with Dana to calibrate before going wide (Topic 8) so I'm not contacting 60 of the wrong people.
Bias-and-noise check. Two risks: (a) Requiring exact senior titles (String 4) under-counts strong engineers at companies that level differently or people returning from a career gap — so titles stay in the fast-lane string only, never as a hard filter on the broad search. (b) Keyword-only matching can under-index engineers (often women and underrepresented folks) who describe impact rather than buzzwords; I'll widen by adding OR "scalable systems" OR "back-end services" and by reading borderline profiles rather than auto-rejecting on a missing keyword. I deliberately left degree out of every filter so I don't screen out self-taught and bootcamp-trained seniors who can clearly do the work.
Rubric
The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.
- Profile → search criteria — 1: vague restatement of the job title with no concrete signals · 2: must-haves translated into real keyword and filter signals · 3: signals are sharp, separate keyword-vs-filter correctly, and trace clearly back to the intake's true must-haves (not the wish-list).
- Channel choice & justification — 1: lists "LinkedIn" with no reasoning, or channels they wouldn't actually work · 2: 4–5 fitting channels each with a why · 3: channels are matched to this profile (e.g., GitHub for backend signal, referrals run day one), with expected yield and a clear primary.
- Boolean strings (AND/OR/NOT) — 1: a keyword list or one naive string, broken/over-broad logic · 2: 3–4 working strings using AND/OR/NOT, quotes, and grouping correctly · 3: each string has a distinct intent (broad, specialist, adjacent-domain, fast-lane), uses synonyms and NOT-exclusions deliberately, and is genuinely runnable as written.
- Filters per string — 1: no filters, filters that over-narrow (e.g., requires a degree), or a location/remote policy that drifts (50 mi here, "NYC-ish" there, a different number of office days than the intake) · 2: sensible location/experience/company filters attached to each string, with the hybrid/remote policy stated the same way every time · 3: filters are tuned per string, name what is deliberately left off to avoid over-filtering, and carry the intake's logistics — 2 days/week in NYC, ~50-mile radius, ET/CT remote — word-for-word identical across every string and table, because a fuzzy or shifting commute story is exactly what loses good candidates at offer.
- Capacity & sequencing — 1: no sense of volume or order · 2: an estimate of how many to contact and what to run first · 3: numbers tie back to a funnel and the 8-week timeline, with a calibration checkpoint before going wide.
- Bias-aware, fair sourcing — 1: no consideration of fairness or over-filtering · 2: names at least one way the search could unfairly narrow the pool and a fix · 3: identifies concrete bias/noise risks (titles, career gaps, keyword self-description) and bakes mitigations into the strings and filters.
- Coherence with the intake — 1: disconnected from Deliverable 1 · 2: clearly sources against the intake's must-haves · 3: every criterion, exclusion, and channel visibly traces from the intake, and reads like one coherent search a hiring manager would trust.