The reason engineering pipelines stall on LinkedIn is not that the platform is bad. It is that the engineers who can ship in production at a senior level often treat LinkedIn as a CV mirror, not a real channel. They update it twice a year, they do not post, and they leave "Open to work" off because they are employed. If your search filters lean on "Open to work" signals or on activity in the last 90 days, you are filtering out exactly the people you want.

The fix is not to abandon LinkedIn. It is to add three or four channels alongside it and learn to read each channel's signal-to-noise. This post is a field guide to the ones we lean on inside imast when we source for technical roles.

TL;DR

LinkedIn is the system of record for a candidate's career timeline. GitHub is the system of record for whether they can write code. Conference rosters are the system of record for whether peers trust them to teach. Personal sites are the system of record for how they think. Use all four. The candidates that look mediocre on one platform almost always look exceptional on at least one of the others.

GitHub: the highest-signal channel for IC engineers

Every individual contributor role worth hiring for has a GitHub answer. The hard part is reading it.

The naive read is contribution graph density. This is mostly noise. Open-source maintainers rack up commits because that is what maintenance looks like; engineers at companies with private monorepos can ship ten times that volume and have a sparse public graph. Density is a floor signal, not a ceiling one.

The signals that matter:

Original repos with non-trivial commit history, especially with issues other people opened. A repo with 30 stars and 12 contributors is usually a stronger signal than a repo with 800 stars and one author.
Contributions to projects the candidate did not start — pull requests against rust-lang/rust, kubernetes/kubernetes, or any framework the candidate uses at work. These get reviewed by senior maintainers who do not know the candidate, so the signal is unforgeable.
Issue threads where the candidate explains, not just reports. Someone who opens "this crashed" is in a different bucket than someone who opens "this crashes because of how tokio::select! handles cancellation; here is a minimal repro and a proposed fix."
Commit messages. A graveyard of "wip", "fix", "more changes" is one kind of engineer. Thoughtful subject lines + bodies that explain the why are another.

GitHub does not index well in a Boolean search. The way to use it as a sourcing channel is by direction, not search: you start from a project that the role demands (a Rust web framework, a database internals library, a frontend bundler) and walk its contributor graph outwards. The people who appear in the contributors list of three adjacent projects are almost always interesting.

Conference speaker rosters and program committees

Conference talks are an underused source. The candidate has self-selected as someone willing to teach in public, the program committee has selected them as someone with something to say, and the content of the talk tells you exactly what they think about. Sourcing from rosters means you also get a free interview screen — watching twenty minutes of someone teaching a topic is more diagnostic than most first-round phone screens.

Where to look:

Program-committee membership at conferences like Strange Loop, QCon, USENIX, RustConf, KubeCon, PyCon, JSConf, ICML, NeurIPS. Anyone trusted to evaluate talks is by definition senior in their domain.
Recent talk archives — YouTube channels for the conferences above publish full session recordings. Filter by year, scan titles, save names for the ones that look on-thesis.
Lightning talks — the bar for a 5-minute talk is lower than a 45-minute keynote, so this surface catches strong mid-career engineers who have not yet been asked to keynote.

Conference rosters are usually overlooked because they are not indexed by sourcing tools. They are a 30-minute manual walk on the conference website. The candidates are worth the time.

Personal sites, technical blogs, and RSS

If a candidate maintains a personal blog with technical posts published in the last twelve months, they are in the top 5% of candidates by signal. Almost nobody bothers; the ones who do are the ones who think clearly enough to want to write it down.

You do not need a clever search to find these. Two practical approaches:

Walk back from blog posts you already trust. When you read a post on a topic adjacent to the role, click the author's name, see what else they have written, follow links to their other work. Five posts later you have a graph of fifteen related engineers, half of whom you would interview tomorrow.
RSS aggregators of "engineering blogs" — Hacker News follows the strong ones; lobste.rs has tighter signal-to-noise for systems engineers; Mastodon clusters by topic. Subscribing to a small set of these as a recruiter is a one-week setup that pays off for years.

Papers and academic authorship

Skipped for product engineering, essential for ML and research roles. The signal is who shows up as first or second author on papers in the relevant venue (NeurIPS, ICML, ICLR for ML; SIGGRAPH for graphics; CHI for HCI). Last-author is the lab head and rarely available; first-author is the person who did the work and is usually transitioning into industry within two years of the PhD.

The mechanical channel is Google Scholar + arXiv, filtered by venue and year, then enriched against LinkedIn or a personal site. The hardest part is timing: the window between paper publication and the candidate accepting a job offer can be as short as 90 days, so the bandwidth needed to keep up is real.

Show HN, Bluesky, technical Discords

These are higher-noise channels, but the noise is well-bounded. A candidate who posts on Show HN with a side project is signaling that they ship for fun, which is one of the highest-correlation predictors of senior IC strength. A Bluesky account with thoughtful technical replies is a softer version of the same signal.

Discords are the messiest of the bunch and require a recruiter who is also a participant. They work best for niche stacks (Bevy, Zig, Elixir) where the community is small enough that the regulars are known by name.

What to do with all these sources

The reason most teams do not bother with multi-channel sourcing is that it does not scale by hand. Walking a contributor graph on GitHub, then matching against LinkedIn for current role + location, then verifying with a personal site, takes thirty minutes per candidate. Done across a shortlist of forty, that is a full workweek.

The shortcut is to use a sourcing agent that runs the walks for you and returns the merged profile. That is the thesis behind imast: one chat-style query — "senior Rust engineers in Berlin with database internals experience" — turns into a fan-out across GitHub, conference rosters, paper indexes, and LinkedIn, with the matches ranked by a scorer that has read all four. You review the shortlist, not the underlying graph walks.

You can do the same work by hand. You should, at least once, so you know what the tool is doing under the hood. After that, the time savings are large enough that a $200/month subscription pays for itself in the first afternoon.

Three things to try this week

Pick the role you have been struggling to fill for the longest. Open the GitHub project closest to its stack. Walk five contributors out from there. Write down the names and current employers; you will be surprised how many you have never seen on LinkedIn.
Find one technical conference your team should be paying attention to. Open last year's program. Scan ten talk titles. Save the speakers whose topics overlap with your roles.
Subscribe to two engineering blogs on RSS for stacks you hire for. After a month, the comment sections and link-outs will have given you a graph of thirty engineers in the space.

Sourcing on one channel is a self-imposed bottleneck. Engineers worth hiring are not hiding; they are just being visible in different places than the place you have been looking.

Sourcing senior engineers outside LinkedIn: a 2026 field guide