candidate_sourcing v1.0.0

name: candidate_sourcing description: "Finding passive candidates for a role: build Boolean and X-ray search strings, pick sourcing channels by role type, check profile evidence before outreach, and write short outreach that cites the person's real work. Ships a working builder, evidence scorer, and outreach linter. Use when sourcing candidates, building a search string, finding people outside job boards, or drafting first outreach to someone who is not job hunting."

Candidate Sourcing

Purpose

Find people who are good at the work and not applying anywhere, then earn a reply with a short message that proves you looked at what they actually did. A passive candidate is employed and not actively job hunting, but may consider the right role. That definition is the whole strategy: job boards will not surface them, titles alone will misrank them, and generic outreach will be ignored.

This skill replaces a prompts only approach with tooling: a search string builder, a channel map, an evidence score, and an outreach linter that blocks a send until the draft cites real work.

Workflow

1. Write the role as evidence, not as a title

• Write one sentence for the outcome the hire owns in the first 6 to 12 months, for example own payments reconciliation so finance closes in one day.
• List 2 to 4 must have skills as things a person does, not tools they list. Go services in production beats Go on a profile.
• List title variants the way candidates describe themselves. A backend engineer, a software engineer, and a platform engineer may do the same job at different companies.
• List deal breakers separately: location or timezone, work authorisation, a licence, a level floor. Deal breakers filter, they do not go in the pitch.
• Note synonyms and neighbouring terms for each skill. Payments work is also called ledger, billing, checkout, and fintech depending on the company.

2. Pick channels by where the work is visible

• Check warm channels first for every role: ATS silver medalists, employee referrals, and people who replied well last time but had bad timing.
• Then pick the one cold channel where real work shows up for this role family. Full map: references/channel-map.md.
• Engineers and data: GitHub, Stack Overflow, talks, and blogs first, LinkedIn as a cross check.
• Designers: Dribbble, Behance, and portfolios first.
• Researchers: publications, patents, and conference proceedings first.
• Business roles: LinkedIn primary, plus associations, speaker lists, and published writing.
• Stop after two cold channels unless both come back thin. Spreading a search across five sites usually means reading none of them properly.

3. Build the search strings with the builder

Run scripts/sourcing.py build instead of hand writing strings. It returns four strings that stay in sync when the role spec changes.

Example:

python3 scripts/sourcing.py build --titles "Backend Engineer,Software Engineer" --must-skills "Go,payments" --any-skills "ledger,fintech,payment processing" --location "Berlin,Amsterdam" --language Go --min-followers 20

Output for that spec:

• LinkedIn or Boolean: ("Backend Engineer" OR "Software Engineer") AND Go AND payments AND (ledger OR fintech OR "payment processing") AND (Berlin OR Amsterdam) NOT recruiter NOT jobs
• Google X-ray: site:linkedin.com/in ("Backend Engineer" OR "Software Engineer") Go payments (ledger OR fintech OR "payment processing") (Berlin OR Amsterdam) -recruiter -jobs
• Google resume: (intitle:resume OR intitle:cv) ("Backend Engineer" OR "Software Engineer") Go payments (Berlin OR Amsterdam) -recruiter -jobs -sample -template -example
• GitHub native: Go payments Backend Engineer Software Engineer location:Berlin followers:>=20 language:Go

Operator rules that matter:

• AND narrows, OR widens inside one idea, NOT or a minus sign cuts noise, quotes hold a phrase together, parentheses group OR terms before AND joins the groups.
• Google uses a space for AND and a minus sign for NOT. LinkedIn Recruiter and most ATS keyword fields accept AND, OR, and NOT directly.
• Google operators for sourcing: site: limits to one site, intitle: and inurl: find resume and profile pages, filetype:pdf finds uploaded resumes. A site: search is called an X-ray search.
• GitHub does not use the same Boolean set. Its user search uses qualifiers. GitHub Docs lists location:, followers: with range syntax such as followers:>=1000 or followers:1..10, and created: with ISO dates. Check the current qualifier list in GitHub Docs, Searching users, before relying on any other qualifier.
• Build strings in passes. Run broad first, read 20 results, then add one must skill, one location, or one exclusion at a time. A perfect string written blind usually returns nobody.
• Size check: under about 10 results, drop a must skill or widen titles. Over about 200, add a must skill, tighten location, or add exclusions like -recruiter -jobs -sample.

4. Check profile evidence before anyone goes on a list

A profile earns outreach only if you can answer, from public work: what did they build or do, with which of the must have skills, at what scope, and how recently.

Score each serious candidate with scripts/sourcing.py score. Write a small JSON file per candidate or per batch entry:

json
{"direct_work_sample": true, "relevant_skill_proof": 0.8, "level_signals": true, "recency": true, "location_or_remote_fit": true, "reachable_publicly": false}

That example scores 85 out of 100 and returns outreach_ready. The rubric weights a direct work sample at 30, skill proof at 25, level signals at 15, recency at 10, location fit at 10, and a public contact route at 10.

• 70 and up: outreach ready, if the hook in step 5 is real.
• 45 to 69: verify first. Open the work sample, do not trust the headline.
• Under 45: skip or watch. Keep the name only if the channel is scarce and the work is promising.

Evidence rules:

• A work sample beats a claim. Code, a portfolio piece, a talk recording, a published article, or a case study outranks a skills list every time.
• Recency means relevant activity in roughly the last 12 months. Older work can still count for level, it just scores lower on recency.
• Never score or filter on protected characteristics, and never infer them from a name, a photo, or a school. Score the work and the fit facts the role requires.
• If two candidates tie, prefer the one with the clearer work sample. That is also the one you can write a real hook for.

5. Write outreach that cites the real work

Use the four part pattern in references/outreach-patterns.md: hook from their work, bridge to the role, role in one line, one concrete ask.

Length and personalisation are not opinions here. LinkedIn reported that InMails under 400 characters got a response rate 22 percent higher than the average for all InMails, and that individually sent InMails performed about 15 percent better than bulk sends. SHRM sourcing guidance points the same way: keep the message to a short paragraph or two, show you read the profile, lead with the impact of the role, link to the full description instead of pasting it, and close with one clear ask and concrete time options.

Lint every draft before it goes out:

python3 scripts/sourcing.py lint draft.txt --channel inmail --evidence "your Go ledger migration write-up"

The linter fails a draft when it is over 600 characters, when it contains generic filler, when the evidence text you passed is not actually in the draft, or when there is no question or ask. It warns on a resume request in message one and on a missing time or duration.

• The --evidence value must be the exact hook text in the message, copied from something the person really made. If you cannot name one specific thing, do not send. Go back to step 4.
• Follow up at most twice, a few working days apart, and add one new true fact each time. A clear no ends the sequence.
• Do not use a subject line built around a job title or the words job opportunity for passive candidates. Use the hook.

6. Close the search and learn from it

• Log for every sourced name: channel, evidence score, hook used, reply or no reply, and outcome.
• After the search closes, compare channels on replies and interviews, not on names found. Cut a channel that gave volume and no conversations.
• Save the final strings and the role spec with the requisition. The next similar search should start from them, not from a blank page.
• Tag strong non hires in the ATS by skill and location so the next search starts warm.

Output Contract

Deliver, for each sourcing run:

• The role spec: outcome sentence, must have skills, title variants, deal breakers, and locations.
• The four search strings from the builder, with the channel each one runs on.
• A shortlist table in text: name or profile link, channel, evidence score and verdict, the one line work fact that supports the score, and location fit.
• One outreach draft per shortlist tier, linted, with the evidence hook shown for each draft.
• A search log summary: channels tried, result counts before and after tightening, reply count, and which channel earned the interviews.

Do not deliver a list of names with no evidence line. That is a name dump, not a shortlist.

Operating Rules

• Use only professional information a person published publicly. Do not bulk collect personal email addresses or phone numbers, do not buy scraped contact lists, and follow GDPR and local privacy law when sourcing candidates in the EU or other regulated regions. Platform terms apply on every channel.
• Be honest in outreach: who you are, which company, which role, and why this person. No fake familiarity, no made up mutual connections, no invented facts about their work.
• One person, one sequence. Check the ATS before contacting anyone, so the same person does not get parallel outreach from two searches.
• The evidence score ranks where to spend sourcing time. It is not a hiring decision, not a screen out tool for applicants, and never a substitute for a structured interview.
• Respect an opt out or a no immediately and record it, so no one on the team contacts them again for that sequence.
• Keep candidate notes factual and work related. Write every note as if the candidate will read it.

Sources

• Workable, Sourcing on Google: Boolean search strings for recruiters. https://resources.workable.com/tutorial/source-google-boolean
• Workable, How to find email addresses: Boolean search for sourcing candidates. https://resources.workable.com/find-email-addresses-boolean-search-strings
• SHRM, Who Are Passive Candidates and How Can You Recruit Them. https://www.shrm.org/in/topics-tools/news/blogs/who-are-passive-candidates-how-can-you-recruit-them
• SHRM, 5 Tips for Writing Better Sourcing E-Mails. https://www.shrm.org/topics-tools/news/talent-acquisition/5-tips-writing-better-sourcing-e-mails
• LinkedIn Talent Blog, How to Improve Your InMail Response Rate, According to LinkedIn Data. https://www.linkedin.com/business/talent/blog/talent-strategy/these-inmails-get-best-response-rates
• GitHub Docs, Searching users. https://docs.github.com/en/enterprise-cloud@latest/search-github/searching-on-github/searching-users