The 90-second scan

A senior-engineering recruiter at a serious company has hundreds of candidates. They scan your GitHub for 90 seconds before deciding to schedule a call.

What they’re scanning for (in rough priority):

1. Pinned repos look real. Not “Hello-world” or class projects. Production-shaped code: README with use case, tests, recent commits.

2. Activity is recent. A green-square graph from two years ago with nothing recent reads as “moved on from coding.” Recent commits — even small ones — read as active.

3. Contributions to known projects. A PR merged into kubernetes, prometheus, the cloud SDKs, or other widely-used projects is more credible than 1000 stars on your own repo.

4. The README of the top-pinned repo. Does it have a clear “what is this,” a “why,” and a working install/run section? Or is it a wall of badges and a sparse description?

5. The code itself, briefly. They’ll open one file. Is it readable? Is there structure? Are there tests in the same directory?

If those five check out, the call gets scheduled. If two or more fail, they skip.

What surprises engineers

Things that engineers think matter and don’t:

• Total commit count. Quality of recent commits > raw count.
• Star count. A 50-star repo with great code beats a 5K-star repo with toy code.
• Number of repos. 5 strong > 50 mediocre.
• README badges. Build, coverage, license, version, downloads. Three is informative; ten is noise.

Things that matter and engineers underweight:

• The commit messages. “Fix bug” vs “Fix tenant isolation race in WithAdminContext (closes #142)” — the second one shows you write clearly and traceably.
• The PR descriptions. A merged PR with a one-line description vs one with a “Summary / Test plan / Risk” structure — the second reads as professional.
• The directory structure. A repo with logical organisation reads as “this engineer thinks about systems.” A flat dump of files reads as “this engineer ships code.”
• Documentation. A repo with a docs/ directory containing operational docs (not just API docs) is rare. Recruiters notice.

The pinned-repos curation

You get 6 pinned repos on GitHub. Use all 6. Curate them.

What I pin (and would defend):

1. My main project (Genie). Active, substantive, has docs. The “this is what I build” repo.
2. A second active project (Bodh). Shows the pattern transfers across domains.
3. A widely-used OSS I contributed to (Spanner Migration Tool). Shows I work in big codebases.
4. A learning artefact (ai-training fork). Shows I learn in public.
5. A focused technical experiment. Smaller scope; shows I can isolate a problem.
6. A career-relevant repo (this blog). Shows I write.

What I don’t pin:

• Class projects.
• Half-finished experiments.
• “Hello world” tutorials I followed.
• Anything I wouldn’t defend in an interview.

The defence test

For each pinned repo, can you answer (in 60 seconds):

• What problem does it solve?
• What’s the biggest design decision and why?
• What’s the next thing you’d improve?
• What surprised you while building it?

If you can’t, the repo isn’t ready to be pinned. Either invest the time to know it that well or unpin it.

What this maps to for hiring

The 90-second scan determines whether you get a call. The 30-minute call determines whether you get the loop. The loop determines whether you get the offer.

The scan is the cheapest stage to influence. A weekend of repo curation moves your scan-pass rate dramatically. Years of skill-building improve the call and the loop; the curation effort is small in comparison and underdone by most candidates.

For my own job-hunt phases, the rule I’ve followed: spend more time on the top 3 pinned repos than on the resume. The repo is the artefact. The resume is the caption.

The recruiter’s 90 seconds are the audience. Write for them.