The Pull-Request Signal Reference: What Code Really Proves

You are about to interview an engineer and you have their public pull requests open in another tab. This reference tells you what each thing in the diff and the review thread actually proves about engineering judgment, and the documented way each signal lies to you. It is for engineering managers, technical founders, developer-relations leads, and technical sourcers who read code to decide, not sourcers scanning stars and contribution graphs. Jump to the row you need and leave.

Most hiring content about GitHub stops at the profile surface: stars, the green contribution grid, pinned repositories. That is a sourcer's view. A technical reviewer reads inside the diff and inside the conversation, where the real signal lives and where the real traps are. The sections below give one row per in-PR signal, a procedure you can run with your hands, and a failure-mode section with real weight, because the ways this goes wrong are the most valuable part of any standard.

Where your attention actually goes during review

Your eyes spend less time on the code than you think. In an eye-tracking study of programmers reviewing pull requests, attention split roughly 57% to the code snippet, 32% to supplemental technical signals such as previous contributions and popular repositories, and 10% to social signals like the author's avatar and follower count. Critically, programmers fixated on social signals more than they recalled doing so.

The practical consequence is that "I only judge the code" is factually false for most reviewers. The mechanism is habitual signal-scanning that people do not notice, which is why hiding the author profile changes outcomes. Here is the measured allocation.

Column source: eye-tracking study means and medians as published by denaeford.me and ResearchGate 346358689.

Read this table as a budget you are already spending whether you plan to or not. The goal of a disciplined review is to move the technical and social time onto things you chose to look at, and to keep the social fixations from leaking into your competence judgment. The rest of this reference is built to make that budget deliberate.

The in-PR signal rows: what each proves and how it lies

Each signal below is a thing you can point at inside a diff or a review thread. For each, the first clause is what it proves, and the second is what it looks like when it misleads you.

Commit granularity and messages

An atomic commit is the smallest meaningful change: it does exactly one thing and nothing more. A pull request built from atomic commits with intent-bearing messages proves the author thinks in discrete, reviewable units and can explain why, not just what. Good messages tell you why something changed; the what is already visible in the diff. The dominant named standard is Conventional Commits, formatted as <type>[optional scope]: <description>, a blank line, an optional body, and optional footers, with subjects in the imperative present tense ("add" not "added"), lowercase, no trailing period, under 72 and ideally under 50 characters.

How it lies: a clean single merge commit can be a squash that erased messy work-in-progress commits. One focused message beats many "fix typo" commits, but one dump commit can also be laziness dressed as tidiness. Read granularity on the branch, not the merge.

Test changes

A diff that adds or modifies tests alongside the logic proves the author treats behavior as something to pin down, not just produce. The strong version changes tests because the behavior changed and leaves a trail of what the new behavior is.

How it lies: tests that assert the implementation rather than the behavior, or tests added only to clear a coverage gate, read as rigor while proving little. Check whether a test would fail if the logic were subtly wrong.

Core-file handling: state, auth, money, concurrency

Core files are new logic, changed behavior, and anything touching state, money, authentication, or concurrency. How the candidate handles these proves engineering level more than any other signal, because this is where mistakes are expensive and irreversible. GitLab encodes this organizationally: database migrations or changes to expensive queries must be approved by a database maintainer, and authentication changes by the authentication team.

How it lies: core judgment can hide in a file you triaged as mechanical. A rename-only file with a logic edit buried inside is a classic.

File count and scoping

A tightly scoped pull request proves the author can carve a change into a reviewable unit. Review difficulty rises with the number of changed files, not changed lines; a "big" pull request in this sense means 20 or more changed files. Strong engineers submit database migrations as separate, dedicated pull requests before the application code that uses them, the expand-and-contract pattern.

How it lies: some cross-cutting changes legitimately span many files, and a low line count can still be a 25-file sprawl. Check whether migrations and config were split out before you read the file count as weak design.

Error handling and types

Explicit handling at boundaries proves the author anticipates failure. In TypeScript, the any type should be used sparingly because it removes static typing; unknown is the safer pattern because it forces a type check before use, and strict: true flags every any. The practitioner split is explicit types at function and method signatures, inference inside bodies.

How it lies: dense type annotations on inferable local variables read as thoroughness but are considered poor style. Over-annotation is fake rigor. Check whether annotations sit at boundaries or clutter bodies.

Review-thread responses

How the candidate responds to challenge proves judgment under pushback better than any clean diff can. The strong signal is revising when the reviewer is right, defending with a reason when the reviewer is wrong, and naming the tradeoff either way.

How it lies: agreeableness is not the same as judgment. An author who accepts every suggestion may lack conviction; one who argues every point may lack it in a different direction. Cite one specific exchange, not a vibe.

The author-label traps: seniority, AI, and the social halo

Identical code is rated differently depending on what you believe about who wrote it. This is the most dangerous category because it feels like judgment and is actually bias. The effect sizes below come from two named studies on identical code.

Column source: Gai/Hou/Tu (SSRN 5255039) and Microsoft Research VLHCC 2026.

Two things matter here. First, in the pre-registered experiment of 1,026 engineers, the bias moved competence ratings while quality ratings for the same code stayed flat. People judged the person, not the product, when author information was visible. Second, the two studies disagree on AI: in an AI-normalized org of 447 engineers, the AI-disclosure badge produced no detected penalty while a seniority label still biased both perceived competence and effectiveness. So AI-label bias is context-dependent, but seniority bias showed up in both settings.

The bias is not in the code. It is in what you believe about the hands that wrote it.

There is a subtler version. One eye-tracking study found that reviewers looked differently at novice versus senior authors yet accepted their pull requests at the same rate. The danger there is not always a wrong decision; it is miscalibrated confidence. You may reach the right verdict while trusting it for the wrong reason, which fails you on the next, closer call.

The defense is procedural, not willpower. You cannot decide to ignore an avatar you have already fixated on. You can decide the order in which you look at things, which is why the procedure below records label exposure as an explicit step and runs scoring first.

Sourcing enough qualified pull requests to read is its own job, and the pool is larger than most reviewers assume. In Refolk's index of professional profiles there are 178,995 TypeScript-skilled professionals in the US alone, which is why a specific, signal-based query beats scrolling a contribution graph. I built the index so you can ask for the exact profile in plain English and spend your time inside the diffs that matter.

How this goes wrong: the documented failure modes

These are the ways a competent reviewer still reaches a wrong read. Each has a check you can run.

Squashed-history false positive. A single clean merge commit reads as senior hygiene but can hide messy work-in-progress commits and even record the merger, not the author, as the commit author. The check: read the source branch or fork and the pull request timeline, not the mainline commit. Where you have the repository locally, git reflog plus git reset --hard on a recovery branch restores pre-rebase history, and git show on the squashed SHA exposes the individual file blobs.

Seniority-label halo. Identical code scores more competent when the author looks senior. The check: score the diff before you open the profile, and write the score down so you cannot revise it silently.

AI-disclosure penalty. A visible AI badge can drag your read of competent code downward, hardest on women. The check: hold your reaction against the measured baseline of 9% overall, 13% for women, 6% for men, and judge the product rather than the method.

Social-signal leakage. You believe you ignore avatars and follower counts, but you fixate on them more than you recall. The check: re-review with the profile hidden and see whether your verdict moves.

Tutorial or clone repositories. A polished repository can be a followed-along tutorial, not original judgment; the diff looks competent and proves little. This is a heuristic, not a measured rate. The check: commit cadence over time, issue engagement, and whether any design decision was contested in a thread.

"Mechanical" file hiding logic. A rename-only or format-only file can carry a buried behavior change. The check: open every mechanical-tagged file and confirm it truly changes nothing that runs.

Many-files-touched misread. A 20-plus file pull request can look ambitious but usually signals weak scoping, while some cross-cutting changes legitimately span files. The check: whether migrations and config were split into separate dedicated pull requests.

Over-annotation as fake rigor. Dense explicit types on inferable local variables read as thoroughness but are considered poor style. The check: whether annotations sit at boundaries or clutter function bodies.

The review procedure, in order

Run these eight steps per candidate. The order matters: file triage comes before deep reading so you spend your 30 to 60 minutes on the files that carry the decision, and label-recording runs before scoring so you can discount bias rather than absorb it.

The funnel percentages are the attention split from the eye-tracking study, reused here as a reminder of where your time goes by default. Your job in the procedure is to make each layer deliberate rather than habitual.

Calibrating against pool scale before you set the bar

Before you decide what a strong pull request looks like, know how many candidates can clear whatever bar you set, because an unrealistic bar is a sourcing failure disguised as a standards failure. The pool differs sharply by stack and geography.

Column source: counts from Refolk's index; ratios derived from those counts.

Read this as calibration, not as a quota. If you require Go contributions with database migration commits, you are fishing in a pool roughly a tenth the size of the TypeScript one, so your per-signal bar should bend toward evidence of judgment rather than volume of output. Where the stack is deep and plentiful, you can afford to weight scoping and review-thread discipline heavily; where it is thin, a single well-handled core file may be the strongest signal available.

What to verify before you call the read done

Run this before the verdict goes into the loop. A read that skips these is a read you cannot defend when someone asks why.

Keeping this reference current

Treat the signal rows as stable and the effect sizes as living. The procedure, the core-versus-mechanical triage, and the failure modes are grounded in how review works and will not drift. The bias magnitudes will: the AI-disclosure penalty is already context-dependent, producing a measurable 9% hit in one org and no detected effect in an AI-normalized one. Re-check the direction of that effect in your own setting rather than importing a fixed number, because whether a visible AI badge biases your reviewers depends on how normal AI use already is around them.

The way to keep it current is to run the blind-score test on your own loop. Have two reviewers score the same diff, one with the profile visible and one with it hidden, and compare. If their competence ratings diverge while their quality ratings agree, you have reproduced the label halo locally and you know your procedure needs the hide-first discipline more than your reviewers believe. Do that once a quarter and this reference stays honest about the one thing it cannot measure for you: your own team.

When you are ready to source the pull requests worth reading rather than scrolling contribution graphs, ask Refolk for the exact signal, name a real repository, a real skill, and a real place, and spend your time inside the diffs.