The Public-Work Interview Screen for Engineers

Deciding whether to interview an engineer from their public work is a judgement call you make dozens of times a quarter, and the internet is full of advice that treats a green contribution graph as proof of skill. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need to score a named engineer's real, shipped, public work and reach an interview-or-pass decision they can defend. It gives you five evidence dimensions, a way to score each one, and the discipline to refuse to score when the public trail is too thin to carry a verdict.

The published reference Reading a Repository explains what a single signal proves. This is the decision layer above it: how to weight code, writing, and project context into one call, and how to handle the blind spot the ranking search results gloss over. Most real engineering work is private. If you score an empty profile as weak, you fail most of the profession.

Why public work is partial evidence, not a resume

Public code is a biased sample of an engineer's real output, so you screen with it knowing it under-counts everyone and disappears entirely for some strong engineers. The numbers make this concrete rather than rhetorical.

In GitHub's 2024 Octoverse, more than 82% of all contributions went to private repositories, spread across 4.3 billion contributions in more than 181 million private repos. The following year's report put private contributions at 81.5% while public repos still made up 63% of all projects, a gap that tells you most projects are public but most work is not. An independent 2018 analysis of the GitHub Archive found that only 17% of GitHub users pushed any code at all in the prior year.

The consequence for screening is direct. A thin or empty profile is the base rate, not the exception. The canonical case in the hiring literature is an engineer who had no public commits, no repositories of his own, and an insignificant follower count, and was the best developer his colleague had ever worked with. Requiring public work is also an equity problem: it locks out people who lack the time or inclination to build outside work hours, with documented skew against women, caregivers, and older developers.

So the screen has two possible outcomes before you score anything: either there is enough authored public work to read, or there is not and you switch to a different form of evidence. Getting that fork in the road right is more important than any individual rubric line.

The five dimensions and what each one proves

Score public work on five dimensions: ownership, code quality, collaboration, communication, and attribution integrity. Each proves one specific thing, and each has a characteristic way of lying to you. A community-sourced evaluation checklist names most of these same axes - quality over quantity, project diversity and ownership, code review participation, commit-message clarity, and documentation and readability.

None of these five proves the candidate can ship inside your specific team codebase. That is what the interview is for. The screen decides who earns the interview, and it does so by confirming that the public signals you can see are genuine and point the same direction.

Reading authorship: forks, copies, and signed commits

Attribution on GitHub is assigned by the commit email address and is therefore spoofable, so you verify authorship from the shape of the history, not the name on the commit. This is the highest-leverage read in the whole screen, because a copied codebase can look like a flagship project to anyone who only counts stars.

The reliable tell for copied code is the initial commit. When someone copies a codebase and uploads it instead of forking, the history opens with one giant first commit that makes it look like they wrote everything at once. A genuine fork does the opposite: it preserves a connection to the original repository, keeping the upstream history and allowing pull requests back. That link is the difference between "I contributed to this" and "I pasted this."

For strong assurance, look for GPG-signed commits, which cryptographically verify that a commit was made by that person and was not tampered with. One caveat on the contributors graph itself: merge commits and empty commits are not counted as contributions, so a reviewer who only reads the graph can undercount a maintainer whose job is integrating others' work.

Once you have tagged each repo as original-authored, fork or contribution, or copied, only the first two categories feed the quality and collaboration read. Copied repos are removed from scoring entirely, and a pattern of them lowers the attribution-integrity score.

The scoring procedure end to end

Run the screen as a fixed sequence so two reviewers reach the same verdict on the same person. The procedure below front-loads the scoreable-or-not decision, because reading code for an hour before realising the trail is too thin wastes the most expensive resource in hiring, which is reviewer attention.

Practitioners disagree on the order between step two and step eight. Some screen out empty profiles immediately to save time. Others insist an empty profile must never count against a candidate and should route straight to a work sample. I side with the second camp: an absence is not evidence, and given the base rates above, an immediate screen-out systematically rejects strong private-work engineers. Use step two to decide the path, never to decide the verdict.

Record the output on a scorecard modelled on how GitHub itself runs take-home reviews: a clear scorecard left as a PR comment, marked against technical criteria, with an Approve or Request-changes status standing in for pass or fail. The point of a fixed format is to limit interviewer bias, and it works the same way here.

Candidate handle set: ______________________
Scoreable? (Y/N):     ______________________

Ownership:               [ PASS / BORDERLINE / FAIL / UNOBSERVABLE ]  note:
Code quality:            [ PASS / BORDERLINE / FAIL / UNOBSERVABLE ]  note:
Collaboration:           [ PASS / BORDERLINE / FAIL / UNOBSERVABLE ]  note:
Communication:           [ PASS / BORDERLINE / FAIL / UNOBSERVABLE ]  note:
Attribution integrity:   [ PASS / BORDERLINE / FAIL / UNOBSERVABLE ]  note:

Unobservable dimensions (list): ______________________
Decision: [ INTERVIEW / PASS / ROUTE TO WORK SAMPLE ]
Reason in one line: ______________________

A candidate does not need all five dimensions at PASS. Two or three strong, genuinely authored signals with the rest UNOBSERVABLE is a clear interview. What sinks a candidate is a FAIL on attribution integrity, because that is not a gap in evidence, it is evidence of dishonesty.

Finding scoreable candidates in the first place

Before you can screen anyone you need a pool where the public trail is dense enough to read, and that pool is smaller and more concentrated than most sourcers assume. In Refolk's index, explicit open-source self-identification is rare even among senior engineers, and it clusters in a few markets and employers.

The US pool is 5.76 times the German one, so a thin public trail is more likely for engineers outside a few hubs. That geographic concentration compounds the private-repo blind spot: the further a candidate sits from these hubs and their named employers, the more you should expect to reach for a work sample.

The second table is the one to internalise. An explicit "open source" self-tag is about 22 times rarer than a mainstream infrastructure skill like Kubernetes. That does not mean open-source engineers are 22 times scarcer than Kubernetes engineers; it means almost nobody bothers to tag it. The absence of the label proves nothing about whether someone does open work, so never filter on the tag alone.

When you source with a query like that, you skip past the two cheapest false signals - forks and stale repos - and land on candidates whose public trail can actually carry a verdict. That saves the reviewer time you would otherwise spend in step two discovering the trail is unscoreable.

For context on where these engineers work, the top employers in each market differ sharply.

How this screen goes wrong

The screen fails in seven predictable ways, and every one of them is a false positive or false negative you can pre-empt with a specific check. This is the most valuable part of the standard, because a confident wrong verdict costs more than an honest "unscoreable." A bad technical hire runs upward of $31,970 in direct recruiting expense alone.

Empty profile read as low skill. The most common and most costly error. A strong engineer with all-private work gets scored as weak. Check: confirm private-contribution graph density and route to a work sample rather than a rejection, per the base rates above.

Copied repo read as authored. An initial commit dumping a whole codebase looks like original authorship. Check: look for a missing fork link and a single giant first commit.

Stars read as quality. A demo repo with thousands of stars but nothing depending on it. A star is a bookmark with a public counter and no attestation anyone ran the code. Check: star-to-fork ratio, monthly contributor activity, and whether any project actually depends on it. Fewer than 5% of the top 10,000 projects ever exceeded 250 monthly contributors, and only 2% sustained it six months, so real sustained activity is genuinely hard to fake.

Fake-star campaign read as traction. Young stargazer accounts with zero followers inflating a counter. Check: stargazer account age and follower distribution. The FTC's 2024 rule banning fake social-influence metrics carries penalties of $53,088 per violation, so this is a real category of manipulation, not a hypothetical.

Team output attributed to the individual. A shared repo credited to one person. Even a strong portfolio can mislead when it reflects team effort. Check: the contributors graph share and the person's own commit diffs.

Stack Overflow reputation read as engineering ability. High reputation, weak shipped code. Check: read two or three answers for reasoning, then confirm against actual repos.

Requiring public work as a gate. Filtering out caregivers, confidential-industry, and non-hobbyist engineers, with documented demographic skew. Check: make public work a plus, never a requirement.

A confident wrong verdict costs more than an honest unscoreable; the discipline is knowing which one you have.

Reading the non-code signals correctly

Non-code artifacts triangulate depth, but each proves something narrower than it appears, so use them to confirm or contradict the code read rather than to stand alone. Stack Overflow reputation is the most defensible depth signal because points require peer upvotes: 10,000 reputation equals roughly 1,000 answer upvotes, meaning hundreds of peers confirmed the person's solutions work in a specific tag. Reading a few of those answers also shows communication clarity.

Its limit is skew. Stack Overflow has awarded 66 million badges to 8.6 million users, heavily concentrated in power users, so most competent engineers score near zero. High reputation is a plus; low reputation is not a minus.

Conference talks carry weight for a different reason. Speakers at major conferences like PyCon, KubeCon, and NeurIPS are pre-vetted by program committees and are usually senior or above, so a talk is a third party's seniority judgement you can lean on. READMEs, docs, and commit messages prove communication and maintainability habits directly: clear, descriptive commit messages indicate good habits, and well-documented projects show care for onboarding. PR review comments prove collaboration when the candidate reviews others' code with constructive, helpful feedback.

When to refuse to score and what to do instead

Refuse to score when the trail cannot carry a verdict: no public pushes in the last 12 months, no original non-fork repos, and no pinned work. Refusing is a valid and often correct outcome, not a failure of the screen. GitHub is explicitly incomplete as a talent market: it misses strong engineers who work mostly in private repos, people with security or confidentiality constraints, and developers who simply do not enjoy building in public.

The documented fallback is a paid trial project that resembles the actual job, kept narrow, and scored against the same qualities you would have read from public work: technical choices, written communication, iteration speed, and handling of feedback. That last dimension, handling feedback, is the one a public repo can almost never show you, which is another reason the trial is worth its cost when the trail is thin.

Keep the screen current by re-checking two mechanisms rather than any fixed number. First, the private-versus-public split: GitHub's Octoverse publishes it annually, and it has held above 80% private, so if that ever shifts materially your base-rate assumptions change. Second, the fake-traction market: the cost per star and the enforcement penalties move over time, so before you weight any star or follower count, confirm it still costs almost nothing to buy. Everything else in this framework is about reading history and diffs, which does not go stale, because a copied codebase looks the same whenever you open it.