GitHub Green Squares Are Not a Hiring Score.

The graph measures visibility before competence

GitHub documents conditions for counting contributions: relevant email association, repository type and branch rules, among others. Private work can be anonymized or hidden; some work performed in enterprise environments is not visible to outside viewers. A blank chart can therefore reflect privacy, employment restrictions, tooling choices or account settings—not inactivity. GitHub contribution criteria. ^{↗ ↗}

Treat green squares as a discovery interface, never as a pass/fail threshold. “Must have active GitHub” is a particularly weak requirement for candidates whose strongest work is proprietary, security-sensitive or built on platforms other than GitHub. ^↗

Four things a repository can actually show

A public project can contain useful evidence if you look at problem framing, ownership, trade-offs and verification. Does the README explain the problem and constraints? Can the candidate explain which part they built? Are decisions about complexity, performance and security visible? Is there evidence of tests, review or failure handling? ^{↗ ↗}

A large commit count alone cannot answer these questions. A tiny, carefully reasoned pull request may show more relevant judgment than hundreds of dependency bumps. Ask for the candidate’s explanation before inferring ownership from usernames or repository statistics. ^↗

A 15-minute evidence review that avoids stalking

Minutes 0–3: read the project description and check whether it matches a competency on the job rubric. Minutes 3–7: inspect one representative change, test or design note. Minutes 7–10: note what cannot be inferred. Minutes 10–15: prepare two job-related follow-up questions. Stop there unless the role requires a deeper, consent-based review. ^↗

Do not inspect personal affiliations, photos, political activity or unrelated public repositories as hiring signals. The EEOC’s guidance on background information and social media highlights nondiscrimination obligations in the US; privacy rules vary elsewhere. EEOC background guidance. ^{↗ ↗}

The ownership trap: stars are not authorship

Stars measure attention to a repository, not a person’s contribution. Commit counts can be affected by squashing, rebasing, branch policies and team conventions. GitHub’s own documentation explains why contributor graphs may omit certain work and why profile contribution rules are not comprehensive employment records. ^{↗ ↗}

Use an ownership prompt: “Choose one decision in this project that you personally made. What alternatives did you reject, and what evidence changed your mind?” A candidate who worked on a private codebase can answer the same prompt using a sanitized architecture diagram or a hypothetical scenario, without sharing protected intellectual property. ^↗

The private-work alternative that protects both sides

Offer equivalent paths: a short structured technical discussion, a candidate-selected sanitized case study or a job-relevant work sample that respects time and accessibility. The employer should decide which competency is required before choosing the evidence format. OPM’s work-sample guidance stresses that tasks should mirror real job activities and be appropriate for skills expected on entry. OPM work samples. ^{↗ ↗}

Do not ask candidates to upload employer-owned code, reveal secrets, bypass access controls or violate confidentiality agreements. A refusal to disclose proprietary work is not evidence of low skill. ^↗

An evidence table recruiters can share with engineering

This table forces reviewers to state the boundary of each observation. If the interview team cannot explain the boundary, the evidence should not be converted into a hiring score. ^↗

The practical rubric: coverage, not ranking

The local tool below records whether each of four competency areas has direct evidence, a follow-up needed or no observation. It returns an evidence-coverage summary and follow-up prompts. It does not assign a person a score or compare applicants. That design is intentional: four ordinal labels cannot support a validated ranking. ^↗

If two reviewers disagree, inspect the underlying example. The question is not “Who gave the higher score?” but “What specific evidence would resolve the disagreement?”

The non-obvious conclusion: private work is a data-quality issue

A team that treats absent GitHub data as zero ability has a missing-data problem, not a tough hiring standard. Public work is selected by the candidate’s opportunities and constraints. The better policy is to keep the competency standard constant while allowing multiple evidence routes. ^{↗ ↗}

Audit how often applicants without public portfolios are asked for equivalent evidence and how often reviewers mistakenly label “not observed” as “not demonstrated.” Fix that language first; it can change a decision without lowering the bar.

Run the operational check

Use synthetic or aggregated inputs only. This local tool does not make individual hiring decisions.

Implementation and evidence guardrails

Before rollout, appoint an owner, define the decision the metric will inform, and record the unit of analysis. Check examples from at least two job families, keep a record of contradictory evidence and use accessible candidate communications. Never use these local calculators to make automated adverse hiring decisions. Re-evaluate after two process cycles; if the observed result contradicts the hypothesis, update the workflow rather than the narrative. ^↗

The decision worth changing this week

Choose one reversible process change, define success and potential harm, and retain the evidence that could prove the idea wrong. Good recruiting operations are measurable without pretending that every candidate can be reduced to a score.