Somewhere along the line, it became a standard interviewer move to open a candidate's GitHub tab while their CV loaded. The reasoning behind it is reasonable. The CV tells you what the candidate says about themselves; GitHub tells you what they actually did. If you can learn something real from their public code before the first interview, why wouldn't you?
The problem is that most of what you think you're learning from a GitHub profile isn't really there. Public contribution activity is shaped by so many things that aren't engineering skill that it's a weak signal at best, and a confusing one at worst.1
What GitHub doesn't tell you
Whether someone is a good engineer. The strongest engineers you'll hire can have thin public profiles. They work at companies that don't open-source anything. They have children. They have hobbies that aren't coding. Their best work is in private repositories you'll never see.
Whether a green contribution graph means anything. A squared grid of green squares can be automated, built from trivial typo fixes, or produced by a side-project the candidate has been paid to keep alive. It can also be produced by a brilliant engineer maintaining a widely-used library. The graph alone doesn't distinguish between these. It just tells you the candidate has been active on github.com.
How someone collaborates. Open-source pull requests often read nothing like day-to-day PRs inside a company. The cadence is slower, the stakes are different, the reviewer relationship is different. A candidate who writes beautiful OSS PRs might still write unclear internal ones, and the other way round.
If your screening decision is influenced by "low GitHub activity means probably not a strong engineer," you are probably filtering out some of your best candidates for reasons that have nothing to do with engineering.
What GitHub can tell you, if you read it carefully
There are three signals worth looking for, and they're mostly qualitative.
How they write. Not the code itself. The README files, the commit messages, the PR descriptions. These are the candidate's own writing, on their own terms, without an interview happening. If they explain what a project does clearly, if their commit messages describe the intent of a change rather than the mechanics, that's a real signal. Written communication skill transfers directly to the job.
What they chose to finish. A profile with four half-finished projects tells you a different story from a profile with one substantial, maintained one. Neither is categorically better. But the choice of what to see through to completion is informative. An engineer with a three-year-old project they still answer issues on is demonstrating something a CV bullet can't.
How they respond to strangers. Scroll through the issues and PRs on the candidate's repositories. How do they respond when a user reports a bug? How do they handle a contributor proposing a change they disagree with? This is, in a very real sense, a preview of how they'd behave in code review.
What not to do with a GitHub profile
Don't count contributions. Don't count stars. Don't judge the aesthetics of the profile itself, meaning the pinned projects, the emoji use, the bio. These are all surface signals that mostly measure how much time the candidate has spent on GitHub's gamification layer.
If you find yourself writing "weak GitHub presence" as a hiring note, stop and replace it with a specific observation. Either you saw something specific in the profile that gave you concern, or the presence-level read isn't doing real work. Most of the time it's the latter.
The cleanest use of GitHub in the process
Use it to generate questions, not conclusions. If a candidate has a project on their profile, pull it up before the interview and find one specific design decision in it. Open the interview with that: "I noticed you used X pattern here instead of Y. Walk me through the choice."
That question does real work. The candidate has to reason about actual code they wrote, in front of you, which is a much stronger signal than the GitHub grid ever was. And it demonstrates to the candidate that you did your homework, which tends to raise the quality of the rest of the conversation.
The profile is a prompt, not a proxy. Used as a prompt, it's one of the better tools in the process. Used as a proxy, it's one of the worse.
-
It's also trivially forgeable. The contribution graph is a grid of backdated commits, and a candidate who wants a greener profile can script commits against an empty repo to produce any pattern they like — including literal pixel-art text or images. Open-source tools for this have existed for over a decade (
gelstudios/gitfitibeing the best-known). The graph was never a reliable signal of engineering output. Today it isn't even a reliable signal of GitHub output — only of whether someone decided to run the script. ↩