Building a Structured Interview From a Candidate's Public Code
You can convert one candidate's public code into a scored, artifact-anchored interview with an AI-authorship check in 60 to 90 minutes.
A generic coding screen tests whether a candidate can solve a problem you invented. A candidate-specific interview tests whether they can defend the problems they actually chose to solve, in public, under their own name. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers who have a named candidate with public repos, merged pull requests, or recorded talks. It walks the full method for turning that public work into a structured, scorable interview - a question set tied to real commits plus a rubric two interviewers would grade the same - in about 60 to 90 minutes of prep, with an AI-authorship and borrowed-code check built in.
Existing guidance mostly stops at "look at their GitHub." That is not a method. Reviewing candidate code before an interview is only useful if it produces something scorable and repeatable. What follows converts specific artifacts into anchored questions and a rubric that survives a calibration review.
Why anchor the interview to the candidate's own code
Anchoring questions to a candidate's real commits gives you a structured interview, and structured interviews are the strongest predictor of job performance yet measured. In Sackett, Zhang, Berry, and Lievens (2022), structured interviews reached a mean operational validity of r = .42, the highest of any method the review examined, after the authors corrected earlier estimates for range-restriction overcorrection. The same recalibration pulled general mental ability down from .51 to .31. So the format you are building here is not a soft supplement to a "real" test. It is the spine of the loop.
The comparison across three reviews is worth keeping in view, because it explains why work samples and coding puzzles lost ground.
| Method | Schmidt & Hunter 1998 | Later revision |
|---|---|---|
| Structured interview | .51 | .42 (Sackett 2022) |
| Work sample | ~.54 | .33 (Roth 2005) |
| Unstructured interview | .38 | - |
| GMA | .51 | .31 (Sackett 2022) |
The work-sample number is the cautionary tale. Its famous .54 rested on only seven primary studies; an expanded meta-analysis by Roth, Bobko, and McFarland (2005) produced a mean validity of .33. A take-home exercise is a work sample, and a work sample is only as good as its design. A structured interview built on the candidate's own public artifacts inherits the validity of the format and sidesteps the take-home's biggest weakness: you already have the sample, freely given, with a commit history attached.
There is a second reason, and it is newer. AI now writes roughly 30% of new code at Google and Microsoft, and a candidate can generate a clean-looking take-home in minutes. Reading-and-critiquing tasks are harder to fake than write-from-scratch tasks, because judgment about someone else's code cannot be pre-generated the way a solution can. Code review as an interview format is not just pedagogically nicer; it is an anti-cheating argument. That is why the borrowed-code and AI checks below are baked into the method rather than bolted on.
What Git artifacts actually prove about authorship
A commit records two actors, and confusing them is the first way this job goes wrong. The author is the person who originally wrote the work; the committer is the person who last applied it. Both carry a name, an email, and a timestamp. Under a rebase, the author and author date remain unchanged while the committer and commit date update - and the same holds for amend, cherry-pick, and patch application. So a candidate can appear as the committer on code someone else authored.
Here is what each artifact establishes, and what it looks like when it lies.
- Author field (
git log --format=fuller): proves who wrote the change. It lies when you read only the committer field on a rebased or cherry-picked commit and credit integration as authorship. - git blame: attributes each line to an author and date by default, so it proves line-level ownership. It lies when a large refactor or a formatting pass reassigns blame to whoever touched the file last.
- Co-authored-by trailers: reveal additional attribution at the bottom of a commit message. Their absence proves nothing; their presence proves shared work you must apportion.
- Merged pull request: proves the change landed and was reviewed. It does not prove the merger wrote it.
The practical move: for each candidate, confirm 3 to 5 artifacts where the candidate is the author, cross-checked with git blame for line-level ownership and scanned for Co-authored-by trailers. If a repo is a fork or vendors someone else's code, diff it against upstream so you do not build questions on borrowed work.
Grep the metadata for AI-authored code first
The cheapest, highest-yield anti-cheating check is a grep of commit metadata, because most AI coding tools self-identify. A census of open-source repositories found that 29 AI coding tools leave identifiable git-metadata traces: actor logins such as copilot-swe-agent[bot], author emails such as noreply@anthropic.com, author names such as Cursor Agent, and Co-authored-by trailers. Signature strings appear in commit messages too. Replit alone produced 385,668 commits containing "Generated by Replit"; OpenHands stamped 7,972; CodeRabbit 297.
number: 385,668
label: Commits stamped "Generated by Replit"
note: One tool's self-identifying signature across a census of 180 million repositories.
Questions practitioners ask
How long does it take to prep an interview from a candidate's GitHub?
Budget 60 to 90 minutes for one candidate. The dossier procedure breaks down to roughly 10 minutes scoping competencies, 15 verifying authorship, 10 running the AI and borrowed-code check, 20 writing artifact-anchored questions, 15 building the rubric, and 10 to 15 calibrating with a second interviewer. The interview itself and the debrief sit on top of that prep.
Can I tell if a candidate's public code was written by AI?
Partly. A grep of git metadata catches tools that self-identify: one census found 29 AI coding tools leave traces, and Replit stamped 385,668 commits with its signature. But watermarking sat near 0% coverage for most models as of April 2026, so clean metadata is inconclusive, not proof of human authorship. The reliable catch for careful evaders is a live conversation about the code's design tradeoffs.
Is a code-review interview better than a LeetCode screen for senior engineers?
For senior-and-above and engineering-manager loops, yes. Practitioner guidance holds that code review better reflects how someone spends their first days on a system, reading before writing, and it is harder to fake with AI because judgment about someone else's code cannot be pre-generated. One senior security engineer reported 2 of 9 interviews were code reviews. It often replaces a coding round rather than adding one.
How many competencies should a technical interview rubric have?
Use 4 to 6 competencies, the range the US OPM recommends, each scored on one scale of 3 to 7 labelled levels with behavioral anchors and an evidence-notes field. More than six competencies dilutes attention; fewer than four fails to separate candidates. Behaviorally anchored scales tend to raise reliability and predictive validity and may reduce bias against protected groups.
Why should interviewers score before the debrief?
Because group-anchored scoring lets one confident voice set the tone before independent judgments exist, and that drift erases the rubric's bias-reduction benefit. Anchored rubrics cut bias effect sizes from d = .59 to d = .23 only when pre-discussion independent scoring is also present. Lock each interviewer's scores and evidence before anyone talks, then calibrate as a panel one competency at a time.
What is the difference between a commit's author and committer?
A Git commit records two actors: the author, who originally wrote the work, and the committer, who last applied it. They diverge during rebase, amend, cherry-pick, and patch application, where the author and author date stay fixed while the committer and commit date update. If you credit integration work as authorship, you can advance someone for code they only merged. Check with git log --format=fuller.
Try it on the search you came here for
Stop building boolean strings. Just describe the person.
Type one sentence. I plan the search, read GitHub, public LinkedIn and Crunchbase records, and the open web as it is right now, and hand back a ranked list with the reason next to every name.
01Describe them
One plain sentence. Role, city, stack, stage, whatever matters to you.
02I read the web live
GitHub, public LinkedIn and Crunchbase records, the open web. Not a database that went stale last quarter.
03You read the shortlist
Ranked, with the reasoning under every name. Open a profile, ask a follow-up, narrow it down.
- Staff backend engineers in NYC who shipped Rust in production
- Series A fintechs in SF under 50 people, growing headcount this year
- Maintainers of fast-growing Rust web frameworks on GitHub
- No boolean, no filters, no seat to buy. One box.
- Read at search time, so a profile updated yesterday counts today.
- Every step visible as it runs, every name with its reason.
500 free credits on sign-up. No card, no demo call. See real searches.