How to Research Technical Candidates Before Outreach

Most outreach to engineers is written from a job title and a skills list. Public technical work can add another layer: something the person published, answered, or maintained. That layer is useful when it is relevant and described honestly. It is not a verdict on skill, seniority, or whether you should write.

Technical candidate research is how you review that public work before you reach out. Discovery is how you find additional people. Neither one is a hire decision. You decide what the evidence means and what to do next. A quiet or missing public footprint does not take that decision away from you.

This article explains what technical candidate research is, how it differs from discovery, what to check across public sources, and how to use what you find without turning public activity into a score.

What is technical candidate research?

Technical candidate research is the practice of reviewing publicly available technical work related to a person already in your pipeline, search, or shortlist. The aim is to understand role-relevant context before outreach. It does not certify that someone can do the job. It shows what public evidence exists, what that evidence appears to support, and what remains unknown.

This is different from sourcing. Sourcing asks who else might be relevant. Research asks what you can actually see about a person you already have in view - a LinkedIn row, a referral, a GitHub URL, an ATS record, or a name from a hiring manager.

Recruiters often mix up where they looked with what they found. Keep those separate.

Sources are the places public work lives. For this article, the relevant examples are GitHub, Stack Overflow, Hacker News, Kaggle, and technical blogs or personal sites. Those match the public platforms Sonar Air discusses and supports. LinkedIn and CVs remain complementary career-history sources.

Evidence is what you actually read on those sources: repositories and projects, open-source contributions, answers and discussions, notebooks, and technical writing. A repository is not a platform. An open-source contribution is not a source. Both are types of evidence you might find on GitHub or another public site.

Sources are where you look. Evidence types are what you might find.

Treat what you find as technical evidence to interpret, not as a scorecard. Much professional engineering work happens in private repositories and internal systems, so public activity is necessarily incomplete.

Why research before outreach

A message based only on a title and skills list gives the candidate very little context for why you contacted them. "I came across your profile" is not a reason. A specific, accurate reference to public work can be - if the work is real, recent enough to mention, and actually related to the role.

Research before outreach does three practical jobs:

It gives you a useful, honest reason to write when you can name a relevant repository, answer, notebook, or post without inventing praise.

It stops you from over-claiming. If you did not find public work, do not pretend you did. Praising "your impressive GitHub" on an empty or fork-only profile damages trust immediately.

It records uncertainty. Write down private employment, unclear ownership, stale activity, or no public footprint so a gap does not quietly become a rejection.

Discovery, research, evidence review, and outreach

These four steps get collapsed into "sourcing." They are not the same job.

Discovery finds people. Research and evidence review interpret public work. Outreach is a later choice.

Discovery is how you find additional candidates. On GitHub, that is GitHub candidate sourcing at strategy level and how to find developers on GitHub at search-workflow level. This article starts after you already have someone to look at.

Evidence review is the careful read: ownership versus a one-line fix, a tutorial versus ongoing work, tag depth versus reputation volume. On GitHub, that deeper pass lives in reading a GitHub profile as a recruitment signal. On Stack Overflow, it lives in how to read a Stack Overflow profile like a hiring signal. This article tells you when those reads matter. It does not repeat their field-by-field guides.

Outreach is a human choice. Public technical evidence can make the first line specific. Career history, a referral, or a hiring-manager request can be reason enough to write even when the public technical layer is thin.

What public technical evidence adds beyond a CV or LinkedIn profile

CVs and LinkedIn profiles are useful for career history: roles, employers, tenure, and stated skills. But they usually summarize work rather than showing the underlying technical artefacts.

Public technical evidence can add:

• Stack in use, not only stack on a skills list - a repository, notebook, or answer thread that actually involves the technology.
• Recency in public, with context - last public activity is not the same as currently shipping behind a private repo.
• Project shape - a maintained tool, a learning exercise, a talky design note, a short bugfix.
• Collaboration and explanation - how someone describes a problem in an issue, a pull request, an answer, or a blog post.

It cannot add a complete career, seniority in closed systems, job-search intent, or proof of performance on your team. For why many strong engineers keep a thin LinkedIn presence, see why great developers are invisible on LinkedIn. Use that article for the channel argument; use this one for the research method once a person is already in view.

Career history and public technical evidence provide different kinds of context. Neither gives you the complete picture on its own.

A practical research workflow

Stay human-led. Do not turn this into points, ranks, or a pass/fail on public visibility.

1. Role criteria. Write down the must-have technologies and the nice-to-haves. Decide, in one sentence, what public evidence would actually be relevant for this hire. Example: "Recent public work in TypeScript services, or clear writing about API design" - not "any GitHub activity."

2. Candidate identity and context. Confirm you are looking at the right person. Handles, names, and personal sites can collide. Note employer and career context from the CV or LinkedIn if you have them. Treat identity as a hypothesis when the name is common.

3. Collect public evidence across sources. Look at the sources that are relevant for the role, not every source every time. A backend hire may show more on GitHub or Stack Overflow. A data or ML hire may show more on Kaggle or in notebooks and posts. You are collecting evidence types - projects, contributions, answers, notebooks, writing - from those sources. You are not scoring how many platforms they use.

4. Assess relevance and context. For each useful item, ask: is this related to the role, is it recent enough to mention, and does it look like owned work or a drive-by change? Read the README, the question, or the post before you read a counter.

5. Note uncertainty. Write what you could not see. Record gaps as unknown, not as negative.

6. See whether public evidence gives you a useful, honest reason to reach out. If it does, you have enough relevant context to make the first line specific and credible. If it does not, you may still reach out from a referral, a CV, or hiring-manager interest. Do not invent a public-work hook.

7. Personalize from what you actually have. Name one real item, or write from career context without fake technical flattery. If you cannot describe the evidence in one honest clause, do not put it in the message.

When the stack is too niche to judge, ask the hiring manager to look at one or two artefacts. That is review. It is not an automated ranking.

What to check before you reach out

You do not need to read every file. You need a consistent first pass that stays attached to the role.

Role relevance

Start with the must-haves. A public Kubernetes operator is weak evidence for a mobile role and useful evidence for a platform role. Nice-to-haves can make outreach warmer; they should not become hidden hard filters unless the hire truly requires them. A profile that lists seven languages is less informative than one artefact that clearly uses the stack you need.

Recency

Ask when the public work last moved. Recent public activity can support a current-stack conversation. A gap can mean private employment, a job change, or simply that this person does not publish. Separate "last public activity" from "currently shipping." Public recency is a hint about the public layer only.

Project context

Read what the artefact is. A tutorial clone, an empty fork, a weekend experiment, a maintained library, and a production-shaped service are different kinds of evidence. A contribution to a famous project might be a one-line typo fix. Always read the change, the README, or the thread - not only the project name. The same GitHub profile can hold owned repositories, drive-by contributions, and writing in a README: different evidence types on one source.

Ownership and depth of involvement

Ask what this person appears to have owned versus visited. Repeated work in a relevant area is usually more informative than a single burst. Do not upgrade a drive-by contribution into "they built X," or a star count into individual skill.

For GitHub-specific reading of pinned repositories, READMEs, pull requests, and one-off versus repeated work, use reading a GitHub profile as a recruitment signal. The same questions apply to a Kaggle notebook series or a sequence of blog posts.

Communication and documentation

READMEs, issue descriptions, answers, and technical posts show how someone explains a problem. That can support recruiter research. It is not proof of team fit.

Evidence across more than one public source

People do not publish evenly. A backend engineer might be quiet on GitHub and active in Stack Overflow answers. A data or ML hire might show more in Kaggle notebooks or posts than in public repositories.

Use sources as places to look. Use evidence types as what you might find:

Do not require a presence on every source. Multi-source research reduces false negatives. It does not create a completeness score. One strong, role-relevant artefact is more useful for outreach than five weak traces.

A labelled composite: a candidate's GitHub looks thin - one old side project - while Stack Overflow shows years of concentrated answers in PostgreSQL. GitHub-only research would have missed the useful evidence.

Tools can reduce tab-hopping when you run this workflow often. That is an evaluation question for GitHub sourcing tools, not a requirement for doing the research by hand.

Evidence gaps, absence, and uncertainty

This is the section that keeps research from becoming a visibility contest.

No public evidence found means you did not see public technical work that you could tie to this person. It does not mean they lack skill. Private repositories, employer policy, non-coding leadership work, and personal preference all produce quiet footprints.

Supporting evidence is a useful phrase for recruiter notes: this artefact appears to support "has worked with X in public," not "is senior" or "will take the call."

Unknown is the honest label for seniority in private systems, performance, motivation, and team fit. Public evidence cannot close those questions.

You do not need a formal four-state model. Write the gap down. If the public layer is empty, outreach - if you still write - should come from the role, a referral, or stated experience, not from an invented public-work compliment.

Public information can still be personal data. If you store or process candidate data, follow your organization's privacy and retention policies and applicable law. See supported data sources and minimization for how Sonar Air approaches this.

Mistakes that turn research into a fake scorecard

Treating stars, followers, or reputation as quality. Those counters measure attention or volume in a community. They do not grade the person in front of you.

Treating commit volume or green squares as seniority. Volume can be automation, formatting, or public-only work.

Reading one artefact as a whole career. One repository, one notebook, or one popular answer is a slice.

Assuming public activity means they want a job. Activity shows engagement with technical work in public, not availability.

Researching only GitHub. You will miss people whose useful evidence is an answer history, a notebook, or a blog.

Building a ranked shortlist from vanity metrics. If you need to prioritize time, prioritize role relevance and whether you can describe the work honestly.

Praising work you did not read. If you cannot name the artefact, leave it out of the message.

Recruiter checklist before outreach

Use this as notes, not as a score. Every item can be "yes," "no," or "unknown."

A pre-outreach checklist for technical candidate research. Notes, not a score.

• I confirmed I am looking at the right person.
• I know the role's must-haves, so I can tell relevant public work from unrelated public work.
• I looked at the sources that actually matter for this role, not every source as a ritual.
• I can name the evidence type I found (project, contribution, answer, notebook, writing) - or I can say I found none.
• I read enough context to avoid calling a fork, a tutorial, or a one-line fix "their platform."
• I noted recency without treating a gap as lack of skill.
• I wrote down what is unknown (private work, ownership, intent, level).
• If I will mention public work in outreach, I can do it in one specific, accurate clause.
• If I found no public technical evidence, I still have another honest reason to write - or I am pausing for more context from the hiring manager, not discarding the person.

How research makes outreach specific

Public technical evidence is most useful when it changes the first line.

When you have a role-relevant artefact: mention it plainly. "Your notes on X in [repo/post/thread]" is enough. Do not upgrade it into a seniority claim.

When evidence is thin but real: say what you saw and stay modest.

When the public footprint is quiet or missing: write from the rest of your process, or wait for a better hiring-manager question. Do not invent a technical compliment to cover the gap.

Move to a conversation when you have a reason you would be willing to repeat to the candidate - public work, a current role, a referral, or a problem your team is hiring to solve.

How Sonar Air supports this workflow

Manual research works for a handful of names. It gets expensive when you repeat the same source-hopping across many technical roles.

Sonar Air is a technical evidence research and candidate discovery platform for recruiters. It helps bring role-relevant public technical evidence together from GitHub, Stack Overflow, Hacker News, Kaggle, and technical blogs so you can review the context yourself. Recruiters define a role profile, run evidence-backed scans, and open matches with links to the public work behind them. It can also discover additional candidates when usual sourcing is not enough.

Scans surface people and evidence; you decide what the evidence means and what to do next. Language models, where they are enabled, may help with summaries and queries. They are not used to score or rank candidates, and they do not make hiring decisions.

See how Sonar Air works.

Frequently asked questions

What is technical candidate research?

Technical candidate research means reviewing publicly available technical work related to someone already in your pipeline or shortlist, so you have role-relevant context before outreach. Sources include GitHub, Stack Overflow, Hacker News, Kaggle, and technical blogs; evidence includes projects, contributions, answers, notebooks, and writing. It supports hiring research. It does not replace interviews or prove quality.

How is research different from sourcing or discovery?

Discovery asks who else might be relevant. Research asks what public technical evidence exists for a person you already have in view. Evidence review asks what that work actually shows and what is missing. Outreach is a later choice, and it can be justified by public work, career history, a referral, or all of those together.

What should recruiters check before contacting a developer?

Check that you have the right person, that any public work you might mention is role-relevant, and that you can describe it without exaggerating. Note recency and likely ownership, and write down gaps. Career history still comes from CVs and LinkedIn. Finding no public technical evidence is not, by itself, a reason to withhold a message.

Does no public GitHub - or no public footprint - mean a weak candidate?

No. Many capable engineers keep production work private or simply do not publish. Treat a quiet footprint as incomplete evidence and continue with the rest of your process. It is not negative evidence, and it is not a disqualifier.

Can public technical evidence prove someone is a good hire?

No. Public work cannot prove seniority in private systems, job performance, team fit, or interest in changing jobs. It can give you a specific, honest reason to start a conversation, or extra context for a hiring manager. You decide what the evidence means and what to do next. For the interpretation limits, see what public technical evidence can and cannot tell a recruiter.

Do you need to read all the code before outreach?

Usually not for a first pass. READMEs, project descriptions, answers, notebooks, and posts are usually enough to mention work honestly. Deeper review belongs later, often with a hiring manager, when you are validating fit.

Final takeaway

Technical candidate research is how you read public work before you write, not how you rank people by how visible they are. Keep sources and evidence types separate. Check relevance, context, and gaps. Use what you find to make outreach specific. If you find nothing public, say so in your notes and use the reasons you do have.

Public technical evidence can support better conversations. It cannot make the hire decision, and it should never be the reason a quiet engineer never hears from you.

If you want that research layer gathered against a role profile for you to review, see how Sonar Air works.