Tracing a Candidate's Real Role in the Project They Claim

A candidate tells the panel they built or led a specific system. Before you spend a full interview loop on them, you want to know from public evidence how much of that system was actually theirs. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers, and it carries one real ownership claim from resume line to verdict: the exact git queries, the intermediate commit counts, the forks where a plausible claim falls apart, and the fork where a modest-looking profile turns out to be the real author.

The output is a verdict in one of four bands - sole author, core contributor, marginal, or riding someone else's work - backed by counts you can defend to the panel.

What "they built it" actually has to survive

A claim of authorship survives only if the git history names the candidate as the author of the load-bearing commits, and the corroborating artifacts agree. Everything in this guide is a way to test that one sentence.

The trap is that the obvious move - open their GitHub, glance at the contributor graph, count the green squares - measures the wrong thing. Two structural facts break naive counting. First, every commit carries two identities, not one: the author, who wrote the change, and the committer, who applied it to the repository, each with its own name, email, and timestamp. Second, common repository operations rewrite one identity and leave the other, so the surface count you see is often an artifact of process, not effort.

Here is the shape of the whole job before the detail.

The rest of this document works one example through that flow: a candidate who claims they "led the authentication service" on a public data platform with more than fifty contributors. I will show the counts I got, the two wrong turns I took, and where the verdict landed.

The two identities on every commit, and why the count lies

Every git commit stores an author and a committer separately, and ordinary operations update one while preserving the other. If you count without knowing which field you are reading, the number is unsafe.

Git stores the name and email of two people per commit. The author is the person who wrote the changes; the committer is the person who applied them to the repository. View both with git log --format=fuller. The fields diverge routinely:

• Cherry-pick keeps the author and author date unchanged, but rewrites the committer and commit date to whoever ran the cherry-pick.
• Rebase and git am (patch application) behave the same way.
• git commit --amend changes the committer, not the author.

None of those is malicious. The load-bearing corruption is different, and it runs the opposite direction from what most reviewers expect.

That inversion matters. Naive advice assumes fakery inflates a small contributor. In practice, the most common false positive is a maintainer on a squash-heavy repo whose shortlog count reflects merge access, not authorship. On my example repo, this was exactly the first wrong turn.

There is partial mitigation. GitHub introduced squashing in 2016 and co-authors in 2018, and now tries to credit every commit author in a PR as a co-author on the squash commit. But the community thread is clear that co-author attribution "is not happening every time," so you cannot rely on it to recover the original author automatically.

Wrong turn one: the shortlog said sole author

My first pass on the example took the claim almost at face value. I cloned the repo and ran the standard commit-share command:

git shortlog -sne --no-merges | head -20

The candidate came back second overall, with 41% of commits touching the auth/ directory across the claimed window. On its own that reads like a core contributor at least, possibly the lead they claimed.

Then I ran git log --format=fuller on the ten foundational commits in auth/ - the ones that introduced the token flow and the session store. On seven of them the candidate was the committer, and the author was three other logins. The repo squash-merges every PR, and the candidate had merge rights. Their 41% was mostly other people's work, applied through their account.

This is the single most valuable check in the whole procedure, so it earns its own detail. --format=fuller prints both identities:

commit a1b2c3d
Author:     Priya Nair <priya@...>
AuthorDate: ...
Commit:     candidate <cand@...>
CommitDate: ...

When Author and Commit differ on the commits that define the feature, the count you took in step one is measuring merge access. That was the fork where the plausible-looking claim started to fall apart.

Three ways to count, and what each one lies about

There are three families of contribution measure. Each gives a real number and each introduces one predictable distortion, so you run all three and read them against each other, never one alone.

Commit share is the fastest and the least trustworthy for the reasons above. Churn - lines added and deleted - is computed per author like this:

git log --author="Full Name" --pretty=tformat: --numstat -w -- auth/ \
  | awk '{a+=$1; d+=$2} END {print "added",a,"deleted",d}'

Weighted ownership is where the real signal lives. The dominant method is the Degree of Authorship (DOA) model used by Avelino's truck-factor algorithm. DOA estimates who the expert is for each file from three factors: whether the developer originally created the file, how many times they modified it, and how much the file has changed since their last edit. The truck-factor algorithm then iteratively removes the developer who is the file expert for the largest number of files.

DOA gives you the two anchors worth citing in a verdict:

• Sole file expert, or more than 50% of file-level DOA on the feature, reads as sole-author evidence.
• The truck-factor smell: a project has the smell if the departure of two or fewer contributors abandons more than 40% of its files. If the candidate is one of those two, they own a real share.

Bus factor is the same idea from the other end: list everyone who committed, sort by contribution, and count how many people you need to cover half the codebase.

The four false signals, and the one command that catches each

The verdict fails in predictable ways. Each false signal has a concrete check, and knowing them is the difference between a defensible verdict and a confident wrong one. This is the most important section in the guide.

Squash misattribution is the one I hit on the example. It is a false positive: the maintainer looks like they wrote every feature. The check is --format=fuller on the anchor commits, plus reading the Co-authored-by trailers the squash may have preserved.

Vendored and imported code. Checking in code you did not write, such as JavaScript libraries, is common and inflates language stats. Linguist treats paths listed in vendor.yml as vendored and excludes them, and .gitattributes can mark paths linguist-vendored or linguist-generated. Inspect that file first and exclude the vendor and generated paths before any count.

Namesake or shared email. A single person can commit under different names or emails and look like several contributors, or two people can collapse into one identity. Counting by name or email both diverge; counting by GitHub username is the most accurate. Build a .mailmap and resolve to the login.

AI co-author trailers. AI coding tools now append Co-authored-by trailers automatically, and when the PR is squash-merged the trailers propagate into the merge commit. Claude Code, for example, adds a Co-Authored-By trailer and a line in the PR description by default. This poisons the co-author field the same way squash poisoned the author field, so removing trailers before counting is now a required step.

Two more failure modes deserve naming because they run the opposite direction and cost you good candidates:

• Mass-rename or reformat commits read as authorship: high churn, zero design. Discount them with git log --follow -M -C -w.
• VCS-only tunnel vision is the false negative. Fritz et al. showed that repository information alone is not enough to capture code ownership, and for roughly a third of projects some real key engineers contributed through code-related activity not captured in the repo at all. A genuine lead can look marginal in the commit log.

Squash poisoned the author field and AI poisoned the co-author field; a count taken before you clean both is not evidence.

The adversarial re-check exists for exactly these. Re-run your counts excluding co-author trailers and merge commits, and confirm no single AI, bot, or squash artifact is carrying the claim.

Resolving one candidate's aliases, pinning the exact repo, and pulling their non-commit artifacts by hand is the slow part of this job. Refolk collapses the sourcing side into a plain-English request, so you arrive at step three with the repo and the login already fixed and can spend your time on the git history instead of the lookup.

Corroborating artifacts: what the commit log cannot see

VCS data alone is documented as insufficient, so a verdict that rests only on commits is incomplete. You need at least two non-commit artifacts that agree or disagree with the commit verdict before you classify.

Developers' interactions that are not logged in version control are relevant to ownership and, importantly, uncorrelated with the VCS data - they carry information the commit log does not. The artifacts worth pulling, and what each one proves:

• PR review threads and issue authorship. Shows design direction and who set the shape of the feature, which never appears in the author field.
• Release-note and changelog credits. Generate the same list the maintainers used with git shortlog v1.0..v2.0. Authoring the release notes for the feature is a strong lead signal.
• CODEOWNERS. A candidate listed there has write permission and is auto-requested for review on PRs touching their paths.
• Conference talks. A talk on a system the candidate also has merged PRs for is corroboration that they can speak to the design, not just the diff.

CODEOWNERS deserves a caution, because it looks like an authorship signal and is not.

Wrong turn two: the modest profile that was the real author

On the same example, a second engineer had only 6% of commits in auth/ and no CODEOWNERS entry. On a pure commit read they were marginal. But --format=fuller showed they were the author on six of the ten foundational commits - the ones the candidate had merely committed. The DOA pass confirmed it: this engineer was the sole file expert on the token flow and the session store. They authored the release notes for the two versions that shipped the feature, and had given a public talk about it.

That is the fork most reviewers miss. A modest-looking profile turned out to be the true author, and a high-count profile turned out to be riding it. The verdict on my candidate landed at marginal, trending toward riding others' work: real merge and review activity, but not the authorship they claimed. It survived the adversarial re-check, and I could defend every band with a specific count.

The procedure, start to verdict

Run these eight steps in order for one candidate and one claimed project. The times are rough; the whole teardown is about two focused hours.

The classification step is a judgement call on two axes: how much the candidate personally authored, and how much of the feature that authorship covers. Read it as a grid.

Why verification rigor scales with how thin the market is

The cost of one misattributed profile is not constant across markets; it rises as the talent pool shrinks. In a thin market, a single verification error is a much larger fraction of your shortlist, so the teardown is not optional overhead - it is what keeps the list honest.

Refolk's index makes the scale concrete. Staff Software Engineers are dramatically more common in the US than in Germany.

The same reasoning applies across title bands. The pool of people you can afford to burn a loop on is finite, and the manager pool that reviews them is finite too.

There is one more time-bound trap. A one-time contributor from years ago can read as an owner if you do not bound the window - Calefato et al. found that 45% of core developers fully disengage from a project for at least a year. Bound every count with --since and --before so old commits are not mistaken for ongoing ownership.

Before you take the verdict to the panel

Run this checklist against your write-up. If any item fails, the verdict is not yet defensible and you should not seat the loop on it.

Keeping the read current

An ownership read has a shelf life, so re-run the anchor checks rather than trusting a verdict from last quarter. Commit history is append-only, but the corroborating artifacts move: CODEOWNERS entries change as people gain or lose write access, and release-note authorship shifts version to version. When a candidate resurfaces for a different role, re-pull the CODEOWNERS file, regenerate the release-note credits for any versions shipped since your last read, and re-bound the commit window to the current claim.

The mechanisms that corrupt these counts also drift. Squash-merge and AI co-author trailers are both live and both getting more common, so the adversarial re-check earns its place permanently: if a new class of automated attribution appears, add it to the list of trailers you strip before counting. The verdict is only ever as good as the last time you cleaned the input.