Interview Drills — Sourcing & Boolean

Open-ended interview questions that mirror the "source this role" take-home and live whiteboard exercise common in tech-recruiter loops. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). Practice thinking aloud: turn a role into must-haves, build and refine a Boolean string, pick the channels where the profile actually lives, and reason about passive talent. The app can role-play these as mock interviews (see mock-interview.md).

The universal sourcing structure: Clarify the role's true goal → translate it into must-haves vs. nice-to-haves → choose the skills/titles/signals to search on → write a Boolean string (AND for required, OR for synonyms/title variation, NOT to strip noise) → pick the channels where that profile actually congregates → refine based on result volume and quality. Use it on almost any "source this role" prompt.

D1

difficulty: easy
concept: must-haves-vs-nice-to-haves Here's a job description for a "Senior Frontend Engineer." Before you search, turn it into a short list of must-haves vs. nice-to-haves on the whiteboard.
Framework: Clarify the role's real goal (what will this person actually build?) → separate true must-haves (without which they can't do the job) from nice-to-haves (bonuses) → flag wish-list items to confirm with the hiring manager → state the seniority bar explicitly so it shapes who you target.
Model answer: "Goal: own the user-facing product in React. Must-haves: strong React/JavaScript, several years of production frontend, senior-level autonomy. Nice-to-haves: TypeScript, design-system experience, a specific framework like Next.js. I'd treat 'CS degree' and 'fintech background' as wish-list items and confirm with the hiring manager — they'd shrink the pool a lot for little real gain. Seniority bar: senior, so roughly 5+ years and the ability to own work independently."
Rubric: Strong answers tie every requirement back to what the person does, ruthlessly separate must-haves from nice-to-haves, and question wish-list items instead of searching on every line. Weak answers treat the whole JD as equally required (keyword-matching), over-filter, and miss great candidates.

D2

difficulty: medium
concept: boolean-search Write a Boolean string to source a backend Python engineer for a fintech company. Talk me through every AND/OR/NOT choice.
Framework: Identify the hard required skill(s) and AND them → list title/synonym variants and OR them inside parentheses → add domain context if it's a true must-have → use NOT to strip predictable noise (recruiters, wrong specialties) → say how you'd loosen or tighten if results come back too few or too many.
Model answer: "(\"software engineer\" OR developer OR \"backend engineer\") AND Python AND (fintech OR banking OR payments) AND NOT (recruiter OR \"talent acquisition\"). AND Python because it's a non-negotiable; the title OR group catches how differently companies title the same job; the domain OR group treats fintech as a must-have but allows adjacent industries; NOT strips recruiter profiles that always pollute keyword searches. If too few hits, I'd demote the domain group to a nice-to-have and drop it. If too many, I'd AND a framework like Django or FastAPI to tighten."
Rubric: Strong answers use AND for true requirements, OR for synonyms/title variation, and NOT for known noise — and explain why each operator is there plus a concrete refinement in each direction. Weak answers chain everything with AND (too narrow), forget title variation, or can't explain a single refinement.

D3

difficulty: medium
concept: channels-and-where-talent-lives Your LinkedIn search for this role returns almost no one usable. Where else do you look, and why?
Framework: Diagnose why LinkedIn is thin (niche skill, underrepresented community, or just a bad search) → match the profile to the channels where that talent actually congregates → name specific niche communities/platforms, not "the internet" → bring in referrals and your warm network of past candidates → say which channel you'd start with and why.
Model answer: "First I'd sanity-check the search — but if it's a genuinely niche skill, LinkedIn under-indexes it. For developers I'd go to GitHub (contributors to relevant repos/languages), Stack Overflow, and language-specific Discord or Slack communities; for designers I'd go to portfolio sites like Dribbble and Behance. I'd lean hard on referrals — current engineers know who's good — and re-engage strong past candidates and silver-medalists from old searches. I'd start with referrals: highest-quality source and the fastest signal of real fit."
Rubric: Strong answers match channels to the specific profile (GitHub for devs, portfolio sites for designers, niche communities for niche skills), prioritize referrals and warm networks, and name concrete platforms. Weak answers just say "try other job boards" or list channels with no link to who they're trying to find.

D4

difficulty: medium
concept: passive-talent Most of the best engineers for this role aren't applying anywhere. How do you find and reason about passive talent?
Framework: Acknowledge that top tech talent is usually passive (happily employed) → describe sourcing on signals of fit and openness rather than "looking for a job" status → target by skills, companies, and projects, not application activity → connect finding them to compelling them (outreach, not just discovery) → set realistic expectations on response rate.
Model answer: "I'd assume the best people aren't job-hunting, so they won't be in an applicant pool — I have to go to them. I'd search by skills and signals: people at companies known for this tech, contributors to relevant open-source, the right seniority and project history. Openness signals help — a recent reorg, a growth-stage employer — but the real lever is outreach: a personalized message that leads with what's in it for them. I'd expect modest response rates and follow up politely, because strong engineers get many recruiter messages and ignore most."
Rubric: Strong answers explain that passive candidates require proactive, signal-based sourcing plus compelling personalized outreach, and set realistic response expectations. Weak answers conflate passive sourcing with posting a job or assume everyone is actively looking.

D5

difficulty: hard
concept: refine-the-search Take-home review: one version of your search returns 3,000 results, another returns 4. Refine both live and walk me through your reasoning.
Framework: For the 3,000 (too broad): AND in a hard must-have, tighten the title OR group, NOT out noise, layer filters (location, seniority, years, company). For the 4 (too narrow): find the over-restrictive term, demote a nice-to-have that's been ANDed in as if required, widen OR groups, relax domain to adjacent industries. State the order of operations and how you judge "good enough" → anchor every move to the must-have list, not a target count.
Model answer: "The 3,000 is too loose — probably missing a hard skill and full of noise. I'd AND the core must-have (e.g., a specific language), tighten the title OR group, NOT out recruiters and unrelated specialties, then filter by seniority and location. The 4 is over-constrained — I'm likely ANDing a nice-to-have (a niche framework or one industry) as if it were required, or my OR group is too narrow. I'd demote that term, widen synonyms (developer OR engineer OR programmer), and relax domain to adjacent industries. The goal isn't a number — it's a shortlist of genuinely qualified, contactable people that matches the must-haves I defined."
Rubric: Strong answers treat result volume as a signal and refine deliberately — adding requirements, NOT, and filters when broad; demoting over-ANDed nice-to-haves and widening ORs when narrow — always anchored to the must-have list. Weak answers add or delete keywords at random, or chase a result count instead of candidate quality.

D6

difficulty: hard
concept: intake-to-search A hiring manager hands you a vague JD: "We need a great full-stack engineer, a rockstar who wears many hats." Turn that into a sourceable search.
Framework: Recognize the JD is a wish-list, not a spec → run a real intake to pin down the true must-haves (which stack? what will they build first? seniority? team context?) → convert the answers into concrete skills/titles/signals → build a Boolean string from the confirmed must-haves → calibrate on the first few profiles with the manager before sourcing at scale.
Model answer: "'Rockstar' isn't sourceable, so I'd push for specifics at intake: which stack (React + Node? Python?), what they'll build first, seniority, and what 'great' looks like — maybe a profile they admire. Say it's React/Node, mid-senior, product-focused. Then: (\"full-stack\" OR \"full stack\" OR \"software engineer\") AND React AND Node AND NOT recruiter, filtered to the right seniority and location. Before sourcing 200 people, I'd send the manager 3–5 profiles to calibrate — confirm I'm on target and adjust the must-haves if I've misread them."
Rubric: Strong answers refuse to source from a wish-list, run a real intake to extract confirmed must-haves, translate those into a concrete Boolean string, and calibrate early with the hiring manager. Weak answers source literally from buzzwords ("rockstar," "many hats") or never involve the hiring manager, guaranteeing weeks of misaligned sourcing.