The Recruiter's GitHub Signal Reference: Trust, Discount, or Ignore

You are mid-screen on an engineer's GitHub, deciding whether to reach out or advance them, and you need to know which of the things on the page you can actually trust. This is the flat lookup table for that moment: jump to one signal, read what it proves, read the specific way it lies to a recruiter who cannot read the code, and leave. It is built for in-house recruiters, sourcers, and founders doing their own hiring, not for engineers running code diligence.

Most repo guides for recruiters do one of two things: they roll a whole profile into a go or no-go score, or they walk one candidate end to end. Neither helps when you have thirty seconds and one question about one signal. Every row here is framed around the hiring decision and names the false positive and false negative, so you know whether to weight the signal, discount it, or ignore it entirely.

How much can a recruiter actually read on GitHub in one pass?

In a sub-minute window you can read recency, pinned repos, and contribution density, and nothing that requires reading code. Authorship and code quality are not readable at that speed.

There is no published figure for how long recruiters spend on a GitHub profile. The number people quote - 7.4 seconds - comes from a 2018 resume eye-tracking study, and a 2024 survey found that 81% of recruiters spend under a minute per CV, with only 1% under 10 seconds. That habit is imported from resumes and misfires on GitHub. A resume is designed to be skimmed; a GitHub profile is not. Apply resume speed to a repository and you systematically over-weight the two most fakeable surface signals, stars and the contribution streak, because those are the only things that read instantly.

The practical move is to split the read into two windows. The surface window is about a minute: identity, recency, pinned repos. Anything that survives that and still looks ambiguous goes to an engineer with a bounded question. Do not try to judge code quality yourself in either window - it is not in your instrument's range.

The signal reference: trust, discount, or ignore

This is the core lookup. Each signal names what it proves about hireability, the false positive that makes it over-read, the false negative that makes it under-read, and the verdict. Weight means it moves your decision; discount means read it only with a cross-check; ignore means it carries no reliable hiring information on its own.

Two of these deserve emphasis because recruiters read them backwards. Stars are the signal people trust most and should trust least. An empty graph is the signal people penalize most and should penalize least. The rest of this reference is largely about those two inversions.

Why stars lie about recency and adoption

A GitHub star is a public bookmark with a counter. It carries no attestation that the person who starred the repo ran it, read the source, or would recommend it. The developer Jon Randy puts it plainly: stars "are a bookmarking feature, nothing more" and "should never be taken as an indicator of quality."

Two design facts make stars actively misleading for a recruiter. First, stars are cumulative and never decrement. A repo that hit eight thousand stars during a launch spike and has not been touched in eighteen months still outranks a project shipped weekly, on the one number that reads first. Second, stars measure passive interest, not usage - most developers star repositories and never use them, and screenshot-driven or AI-adjacent repos attract stars from people who never cloned the code.

The fix is a two-field cross-check. Never read the star count alone. Read it against the last-commit date and the recency of merged pull requests. High stars plus a recent commit stream is a maintained project. High stars plus a stale commit history is an artifact, not a current skill signal. If you want to test real usage rather than interest, look at package downloads on npm or PyPI and the quality of open issues, not the counter.

Why the empty graph is a false-negative machine

An empty contribution graph carries almost no negative information about whether someone codes. Four independent, documented mechanisms each turn a genuinely active engineer's public footprint empty, and because they stack, "empty GitHub" is close to useless as a reason to pass.

By default, the contribution graph shows only activity from public repositories. An engineer who works entirely in private repos and never enabled private-contribution visibility reads as blank to you. If their employer uses SAML single sign-on and you are viewing from outside that organization, you see only anonymized org activity. Commits made inside a fork do not count toward contributions unless they are merged into the parent via a pull request. And commits made with an email address not linked to the GitHub account never attach to the profile at all.

The population this hits hardest is senior engineers at private-repo shops - finance, defense, big tech - who legitimately show thin public footprints. Do not penalize them. Escalate to an engineer or simply ask the candidate where their work lives. And when you do see a blank graph, run the check before drawing any conclusion: verify the commit author email by appending .patch to a commit URL, which reveals the address a commit was authored with. Note also that contributions can take up to 24 hours to appear, so a very recent action may not have surfaced yet.

What actually counts toward the contribution graph

The graph counts some actions always, some sometimes, and some never, and knowing which is what lets you read a green calendar correctly instead of taking density at face value.

Creating a repository and forking one always count, with no further condition. That matters because both are cheap and neither proves the person wrote code. Commits, issues, pull requests, and reviews only sometimes count, under specific conditions. A commit appears only if it is on the default or gh-pages branch of a standalone repo and uses a linked email; issues, PRs, and discussions count only if opened in a standalone repo, not a fork.

The asymmetry is the whole lesson. Because forking and repo creation always count, a graph can be green from activity that proves nothing about code authorship. Because fork commits are discounted until merged, an external merged PR is a scarce, hard-to-game collaboration signal. Merged PRs beat raw commit volume for exactly this reason: forking is free, but a maintainer accepting your change into a repo you do not own is not.

To confirm original authorship, open the repo and look under its name for the "forked from" line, which points at the upstream parent; original repos have no such line. Then open the repo's own commit history and check that the candidate authored commits with real granularity, not a single "initial commit" dump. The repo's contributors graph shows the top 100 contributors but excludes merge and empty commits, so use it as a fast filter for who actually shipped code.

Reading these conditions by hand on every profile is slow, which is where Refolk removes friction: instead of opening thirty profiles to find who has merged external work, you ask for the signal directly and get the people who have it. That inverts the usual order - you start from the scarce, hard-to-fake signal rather than hunting for it profile by profile.

The mid-screen procedure

This is the order practitioners follow when checking one profile mid-screen. The whole surface pass runs in a few minutes; anything hinging on code quality leaves your hands and goes to an engineer.

Two ordering notes. Some practitioners check the visibility settings (step 3) before reading the graph (step 2), and either order works as long as you do both before drawing a conclusion. And no source formally sequences the star cross-check against the collaboration read - run them in whichever order the profile makes convenient.

The failure modes that make each signal lie

This is the section to keep open. Each entry names how a recruiter gets a signal wrong, and the specific check that catches it.

Blank graph misread as inactive. The false positive is "not a coder." Before you believe it, ask whether the work was done in private repos, behind SSO, in forks, or with an unlinked email. Verify by appending .patch to a commit URL to see the author email.

Green graph dominated by forks. A dense calendar can be almost entirely forks and personal repos, reading as "prolific contributor" when little of it is original or collaborative. Check for the "forked from" line on the repos driving the density, and look for merged PRs into repos they do not own.

High-star repo, dead project. Stars do not decay, so an eight-thousand-star repo untouched for eighteen months still looks impressive. Check the last-commit date and merged-PR recency, not the star count.

Stars inflated by demos or bots. Screenshot-driven and AI-adjacent repos attract stars from people who never ran the code. Check package downloads and the quality of open issues instead of the counter.

Contribution streak gamed. A single trivial daily commit keeps a streak alive. Check whether commits touch real code on a default branch versus README or whitespace churn.

"Empty" senior engineer. Engineers at private-repo employers legitimately show thin public footprints. Do not penalize; escalate to an engineer or ask directly where their work lives.

Namesake or claimed account. The profile may not be the candidate's at all. Confirm via linked site, email domain, or bio before you weight a single thing on it.

Language breadth read as depth. Many languages listed often means tutorial repos, not production skill. Check depth in one repo over breadth across many.

Why market scarcity changes how much a misread costs

How aggressively you should trust a thin GitHub signal depends on how rare the skill is, because in a thin market discarding one misread profile removes a larger share of the entire pool. Scarcity, not just skill, should set your outreach effort and your tolerance for ambiguous signals.

The size of a skill's talent pool also predicts how much GitHub signal exists to read in the first place. Larger, older-ecosystem communities produce more public artifacts, so an absent footprint means more in a big open-source community than in a small or enterprise-heavy niche.

In Refolk's index, the US Go pool is 4.5 times the Rust pool. Absence of a GitHub footprint carries more weight for a Go engineer, where public artifacts are abundant, than for a Rust engineer in a smaller, more enterprise-heavy community. Geography compounds this.

The US Rust pool is roughly 6.8 times Germany's. When you are sourcing Rust in Germany, the empty-profile false negative is far more expensive, because throwing away one misread profile removes a larger fraction of the reachable talent. In a thin market, lean toward escalating or asking rather than discarding on an ambiguous GitHub read.

Before you decide: the verification checklist

Run this before you let a GitHub read move a candidate forward or hold one back. It is built to catch the false negatives that cost you good people and the false positives that waste an interview slot.

Keeping this reference honest over time

GitHub changes its contribution rules and profile surfaces periodically, so treat the counting conditions in this reference as a mechanism to re-check, not a fixed fact. The safest ground here is the documented behaviour: what counts toward the graph, how forks are labelled, and how private and SSO visibility default. When in doubt, confirm against GitHub's own profile contributions reference rather than a blog.

Two things will not change, because they follow from design rather than policy. Stars are a cumulative bookmark counter with no attestation, so they will keep lying about recency until GitHub changes what a star means. And a merged pull request into a repo someone does not own will stay hard to fake, because it requires another person to accept the work. Anchor your trust on those two, keep the counting conditions under review, and escalate anything that needs a code read. That is the whole discipline: weight the scarce signals, discount the cumulative ones, and refuse to read an empty graph as a verdict.