Candidate Sourcing

Candidate Sourcing Pipeline

An end-to-end skill that takes a hiring role and produces ready-to-send Gmail drafts for strong candidates — handling discovery, LinkedIn verification, email enrichment, personalized copy, and draft creation in one continuous workflow.

The pipeline has five phases. Each phase feeds into the next, and the skill is designed to run them in sequence with minimal human intervention. The user reviews the final Gmail drafts and clicks send.

Phase 1: Define the search and find candidates

Clarify the role and company

Before searching, extract or confirm these details from the user. Do not assume any of these — always ask if not provided:

About the hiring company (needed for outreach in Phase 4):

• Company name
• What the company does (1-2 sentences)
• Stage/traction (e.g., "Series A, $10M raised" or "500-person public company")
• Location / remote policy
• The sender's name and title (for the email signature)

About the role and ideal candidate:

• The role title (e.g., "Founding ML Engineer")
• 2-3 core technical problems the role involves
• Target companies, research labs, or communities to search
• Any school/alumni connections to prioritize (e.g., "IIIT Hyderabad alumni")
• Location preferences or constraints
• How many candidates the user wants in this batch

About the ideal candidate profile:

• Seniority level (e.g., "3-7 years", "senior", "staff+")
• Must-have technical skills or domain expertise
• Nice-to-have signals (open source contributions, publications, specific frameworks)
• Any deal-breakers or filters (e.g., "no FAANG lifers", "must have startup experience")

Use the company and role details to research what makes this company compelling to candidates — check their website, recent funding, product launches, or press mentions via the Crustdata MCP's web_search_live tool. This research informs the company blurb in Phase 4.

Search by technical output, not job title

Three signals matter more than years of experience or company prestige:

Proof of work — papers they authored, tools/repos they built with real usage, blog posts with technical depth, open-source contributions, demos or benchmarks they released.

Hunger — technical opinions posted publicly, Medium/Substack articles, conference talks, being cited by others, active GitHub beyond just commits.

Relevance — their specific work maps to the actual problems in the role, not just adjacent domains.

Search sources and patterns

Crustdata `person_search` (via the Code Mode execute tool) for structured search:

// model query: find ML engineers at Company Name
const r = await callTool("person_search", {
  filters: { op: "and", conditions: [
    { field: "experience.employment_details.current.title", type: "(.)", value: "ML Engineer" },
    { field: "experience.employment_details.current.company_name", type: "[.]", value: "Company Name" },
  ]},
  limit: 20,
});
if (!r.ok) return { error: r.message };
return r.data.profiles.map(p => ({
  name: p.basic_profile?.name,
  title: p.basic_profile?.current_title,
  url: p.social_handles?.professional_network_identifier?.profile_url,
}));

Research papers — search arXiv, Google Scholar, Semantic Scholar for the core technical problem. Look at first/second authors, especially those not at top-5 labs.

GitHub — search repos by topic/keyword, look at meaningful contributors (not just maintainers).

Crustdata web search (web_search_live) — "[technical problem]" site:arxiv.org, "[name]" "[company]" github, "[community]" alumni engineer ML.

Output from Phase 1

A list of candidates, each with: full name, current role, current company, any school/community connection, and one specific piece of work that makes them relevant (paper, repo, tool, post). This "proof of work" note is critical — it becomes the basis for the outreach email opener in Phase 4.

Phase 2: Verify LinkedIn URLs

Never guess or construct LinkedIn URLs. This is the single most common source of errors in outreach. Guessed URLs like firstname-lastname or firstname-lastname-school frequently 404 or point to the wrong person. Real LinkedIn slugs are auto-generated and look like david-park-086833264 or hongjunchoi92 — they are not predictable from a person's name.

Waterfall approach

Use this exact priority order. Stop as soon as you get a confident match.

Step 1: `person_search` (always try this first)

// model query: verify LinkedIn URL for Person Name at Company Name
const r = await callTool("person_search", {
  filters: { op: "and", conditions: [
    { field: "basic_profile.name", type: "[.]", value: "Person Name" },
    { field: "experience.employment_details.current.company_name", type: "[.]", value: "Company Name" },
  ]},
  limit: 3,
});
if (!r.ok) return { error: r.message };
return r.data.profiles.map(p => ({
  name: p.basic_profile?.name,
  headline: p.basic_profile?.headline,
  url: p.social_handles?.professional_network_identifier?.profile_url,
}));

Extract social_handles.professional_network_identifier.profile_url — this is the verified canonical LinkedIn URL.

Tips:

• Company names have variations ("Google DeepMind" vs "DeepMind" vs "Google") — try shorter names first, then variations
• If 0 results, try past employers (experience.employment_details.past.company_name) or just the person's name with a broader filter
• If multiple results, match by headline, location, or education
• Run these as a single execute script that fans out independent lookups with parallelMap (batch the candidate list, then map) for efficiency

Step 2: `web_search_live` (fallback when Step 1 returns 0)

// model query: find LinkedIn profile for Person Name at Company
const r = await callTool("web_search_live", {
  query: "Person Name Company distinctive-keyword",
  site: "linkedin.com",
});
if (!r.ok) return { error: r.message };
return r.data.results;

Verify the result matches by checking the snippet for employer/role alignment. Don't just grab the first LinkedIn URL.

Step 3: Mark as unverified (if both fail)

Keep whatever URL exists but add a note: "LinkedIn URL unverified." Never fabricate a URL.

Slug comparison

When verifying an existing URL: extract the slug (part after linkedin.com/in/), strip trailing slashes, compare case-insensitively. Different slugs = wrong URL, use the verified URL from social_handles.professional_network_identifier.profile_url instead.

Real mistakes this prevents

These are actual errors from production outreach campaigns:

URL format

Always use https://www.linkedin.com/in/{slug} — never bare linkedin.com/in/ without the protocol. Characters like ü need URL encoding (%C3%BC).

Phase 3: Find email addresses

Every candidate needs an email address for the Gmail draft. Use this priority chain.

3A: Business email via Crustdata enrichment

Use person_enrich (via the Code Mode execute tool). It takes an array of LinkedIn URLs in professional_network_profile_urls (≤25 per call — chunk(urls, 25) then parallelMap), and field GROUPS (not leaf names) in fields. The contact group returns emails and phone numbers:

// model query: enrich business emails for a batch of candidate LinkedIn URLs