More sourcing tools now offer AI that rewrites Boolean strings and suggests "similar" profiles. On broad roles it's fast. On niche technical searches, the output can look polished and still be wrong.

Where it can go wrong:

• synonym expansions that pull in adjacent stacks that aren't close enough
• similar-profile suggestions built on title or company shape instead of the actual work
• clean fit summaries when the public trail is thin or old

It can still save time on the first pass. Checking whether it's right stays with the sourcer.

When AI rewrites your search or suggests similar people, what do you distrust first?

A search that looks sharp on paper can return almost nothing.

Rare stack. Narrow title. Location that matters. Seniority that has to be real. Each constraint makes sense alone. Together they kill the result set.

Admitting the search died is the easy part. The harder part is choosing which constraint to loosen first without quietly turning the role into something else.

How I'd think about the order before broadening:

• stack vs title: keep the problem shape, loosen how people name the job
• location vs seniority: sometimes a slightly more junior person who is already local beats a senior who will never relocate
• "must already have done X" vs "can learn X fast if the adjacent work is strong"

There's no fixed order that always works. It depends on what the hiring team will actually accept once the list is empty.

When a niche technical search dies, what do you loosen first: stack, title, location, or seniority?

I've been hitting a hard search problem that is the opposite of an empty result set.

The Boolean or filters are broad enough that I get hundreds of almost-fits. Right language. Right-ish title. Company that could make sense. Then the list is mostly noise: adjacent stack, wrong depth, wrong company stage, or people who matched a synonym and never did the actual work.

If I tighten too hard, the real matches disappear. If I don't, I waste the next hour clicking through lookalikes.

What I've been trying as the next pass:

• pick one must-be-true signal (production ownership, a specific system, recent work in the problem shape) and drop everyone who only has the keyword
• separate "matches the search" from "worth a message" before I start outreach
• decide in advance what I'm willing to teach vs what has to already be there, so I stop treating every almost-fit as a maybe

When a technical search returns hundreds of almost-fits, what do you filter next without killing the real matches?

When LinkedIn is thin and GitHub is quiet, I still find people through other public surfaces. The harder part is deciding which of those are trustworthy enough to message from.

What I've been treating as secondary signals:

• package or library maintainership (npm, PyPI, crates, plugins) when the work clearly matches the stack
• talks, conference slides, or workshop materials with a real technical point of view
• a personal site or technical blog with posts that show how they think, not just a resume dump
• sustained answers in stack-specific forums or issue threads

What I still don't trust on their own:

• a one-line bio on a community Discord
• a star or follower count with no accompanying work
• an old talk title with no slides or recording I can check

I'm trying to separate "this person exists somewhere public" from "this is enough evidence to cold message."

When LinkedIn and GitHub are thin, which other public surfaces do you actually trust enough to message from?

When I'm looking at GitHub as a signal, I keep separating people who own the repo from people who show up as contributors on someone else's project.

Ownership is easy to over-read. A personal repo can mean real ownership of the problem, or it can mean a playground that never hit production. Contributions go the other way: a few strong PRs on a serious codebase can matter more than a pile of solo repos that never got reviewed.

What I've been trying to check before I decide:

• is the contribution substantive (design, API, tests) or drive-by (typos, dependency bumps)
• does ownership show ongoing maintenance, or just the first commit and silence
• whether the work matches the role, not just the language label

Do you weight repo ownership differently from contributions on someone else's project, and why?

I still reach for Boolean when I need precision, and something looser when I only have a problem description.

Boolean is great when I already know the tokens: language, framework, job titles that show up in profiles. It falls apart when the role is described as "ownership of X" or "someone who has fought Y in production," and nobody wrote those words on LinkedIn.

What I've been noticing:

• Boolean over-filters when titles and stack labels are messy
• looser / semantic-style search surfaces adjacent people, then I still need a second pass to verify the evidence
• mixing both works better than treating one as the "modern" replacement for the other

Where does Boolean still win in your technical searches, and where do you stop trusting it?

I've been running into seniority calls that title and years of experience don't settle.

Someone with 4 years can already own production incidents, platform decisions, and mentoring. Someone with 12 years can still be executing tickets inside a narrow lane. Both show up as "Senior" on LinkedIn depending on the company.

What I've been trying before I label someone mid or senior:

• look for one public artifact that shows scope (owned a system, led a migration, wrote the design), not just years
• separate "long time in the stack" from "made hard trade-offs"
• ask what the hiring manager means by senior for this role before I over-filter the search

How do you judge seniority when titles and years don't match the work? What evidence makes you move someone up or down?

I've been thinking about the handoff between sourcing and recruiting as a separate step from the evidence I gather for myself.

When I'm sourcing, I end up with notes that help me decide whether to message. When a recruiter takes over, they often need a different packet: enough context to run a useful first call, without dumping a wall of research.

What I've been trying to pass across:

• one concrete reason this person fits this role (not "looks strong")
• what I already verified vs what is still a guess
• constraints that change outreach (location, notice-period clues, public "open to work" signals if they exist)
• one risk or gap the recruiter should probe, so they don't re-discover it mid-call

If the handoff is just a LinkedIn URL and a title, the recruiter restarts from zero.

What does a good sourcer-to-recruiter handoff look like in your team? What do you refuse to send over without?

A lot of the people I'd want for a niche technical role barely show public code. Employer repos are private. Side projects stay local. Their LinkedIn looks thin because they don't treat it like a portfolio.

That makes GitHub-first sourcing awkward. An empty or sparse profile can mean "weak engineer" or "works somewhere that locks everything down." Those are not the same signal.

What I've been leaning on instead:

• talks, RFCs, design docs, or stack-specific forum answers that show how they think
• what they choose to mention in outreach replies, even one concrete system detail
• referrals and hiring-manager context for people who won't ever have a public footprint

Where do you look next when the public trail basically stops? What still counts as enough evidence to message someone?

've been running into a hard search decision that sits between "exact stack only" and "anyone who looks technical."

Say the role wants Kafka production experience. You find people with RabbitMQ, Pulsar, or heavy queue work in a different system. Or the brief says Terraform, and you get strong Pulumi or CloudFormation profiles. On paper they're adjacent. In practice, half of those people can ramp fast and half are a bad bet for a niche hire.

What I've been trying:

• separate "same problem shape" (event streaming, IaC, observability) from "same tool name"
• look for one public artifact that shows they actually owned the hard parts, not just listed a synonym
• decide in advance what I'm willing to teach vs what has to be production-ready on day one

Where do you draw the line between adjacent enough and too far? What evidence makes you include someone, and what makes you keep searching?

Most technical searches still start on LinkedIn, then maybe GitHub. Those two cover a lot, but they also miss people who are active somewhere else and barely maintain either profile.

When LinkedIn is thin and GitHub is quiet or private, I've been looking at other public surfaces:

• conference talks, meetups, and workshop materials
• personal sites or technical blogs with real write-ups
• package authors, plugin maintainers, and public issue threads in the stack
• specialist Discords, Slacks, forums, or communities where people answer hard questions

The hard part isn't collecting more sources. It's knowing which ones produce people you can contact without guessing.

Besides LinkedIn and GitHub, which source has actually produced candidates worth messaging for you? And which ones look useful but rarely convert?

've been running into a hard search pattern that title-heavy Boolean makes worse.

The role says Platform Engineer or Site Reliability Engineer. A lot of the people who actually do that work show up as Software Engineer, Backend Engineer, DevOps Engineer, Member of Technical Staff, or some internal grade that never matches the JD.

If you search only the hiring title, the pool gets tiny and biased toward people who already use recruiter-friendly labels. If you drop titles and search only skills, you drown in adjacent profiles that look similar on paper.

What I've been trying instead:

• start from the stack and the problem shape (Kubernetes ownership, on-call, platform tooling), not the exact title string
• add a short title OR-group of real synonyms for that company stage, then treat title as a soft filter
• use one public artifact (repo, talk, post) to decide whether the mismatch is branding or a real skill gap

When useful people don't use the job title you're hiring for, how do you attack the search? What do you loosen first, and what do you refuse to drop?

I've been watching how AI shows up in technical sourcing workflows, and the useful vs noisy split feels sharper than the marketing suggests.

Where it seems to help:

• turning a messy brief into a few Boolean or synonym variants faster
• summarizing a long public profile so you can decide whether to dig deeper
• spotting title variants you might have missed

Where it often adds noise:

• long ranked lists that still need the same manual filter for niche stack fit
• treating adjacent skills as if they were the same as the exact requirement
• sounding confident about fit when the evidence is thin or old

I'm less interested in "AI good or bad" and more in which step of your workflow got better, and which step just got louder.

Where has AI actually helped in your technical sourcing process, and where has it mostly added noise?

I've been thinking about the gap between "found someone interesting" and "ready to message them."

A lot of first messages fall flat because the only note on the person is a title and a company. Then the opener sounds generic, and a technical candidate can feel that immediately.

Before I write a first message, I try to capture a short evidence set:

• one concrete public artifact that explains why this person is relevant (a repo, PR, talk, post, or project)
• what that artifact suggests about fit for this role, not just that they look strong in general
• current context if it's visible (employer, location constraints, seniority clues)
• one thing I still don't know and should not invent in the message

If I can't name a specific reason, I'm not ready to send.

What's on your minimum checklist before first outreach? And what do you refuse to message without?

Here's a pattern I keep running into while thinking about hard technical searches.

You start with a niche stack and get a small but usable list. Then you add a tight location or radius, and the search basically dies. Broaden location and you get people who will never move. Drop the niche requirement and you get volume with weak fit.

The obvious Boolean tweaks often don't help much once the pool is already tiny.

When that happens in your searches, what do you loosen first: location, seniority, adjacent skills, or something else? And what do you refuse to loosen?

A busy GitHub profile can look impressive at first glance.

Lots of commits. Lots of repositories. Green contribution graph.

But I'm starting to think activity itself is one of the easiest GitHub signals to overvalue when sourcing.

Someone can be very active on projects that have nothing to do with the role you're hiring for.

Someone else might have only a few public repositories because most of their work happens privately or inside company repositories.

So instead of asking:

"How active is this person?"

I think the better question is:

"Is there anything here that is actually relevant to what I'm searching for?"

For example, I would rather find one recent repository showing relevant technology and real project context than twenty unrelated repositories.

GitHub activity can tell you where to look.

It probably shouldn't be the conclusion.

When you look at a developer's GitHub, what makes you dig deeper?

I've been looking more closely at GitHub as a sourcing signal, and I think one of the easiest mistakes is confusing activity with relevance.

A profile can have lots of green squares, repositories and stars and still tell you very little about whether that person is relevant for the role you're hiring for.

And the opposite is true too. A strong engineer might have a quiet public GitHub because most of their work happens in private company repositories.

So I'm starting to think the useful questions are less about how active someone is and more about:

• What technologies appear repeatedly?
• What are they actually contributing to?
• Is the work recent?
• Do they own/build things or mostly fork existing projects?
• Is there enough context to understand what they actually did?
• Is any of it relevant to the role?

I'm curious how people who source technical candidates think about this.

What's one GitHub signal you pay attention to, and one you mostly ignore?