What a developer's commit history actually tells you

The PR was 1,200 lines long. It deleted 900 of them.

A hiring manager at a Series B infrastructure startup found this contributor while searching GitHub for engineers who'd worked on distributed tracing. No LinkedIn profile. A total of 14 followers. The contributor had been quietly maintaining a module inside a large open source project for four years, reviewing other people's code, flagging edge cases, deleting dead weight.

They got on a call. Three weeks later she was their first senior infrastructure hire.

The hiring manager told me afterward: "I almost filtered her out because she didn't have impressive stars or a big follower count. I almost used the wrong metric entirely."

That wrong metric is everywhere. Most recruiters evaluating GitHub profiles spend their time looking at stars on personal projects, total commit count, how many followers someone has. These numbers are easy to find and they feel like signals. Most of the time, they're noise.

Here's what to look at instead.

Commit history length vs. commit history pattern

Volume is almost meaningless on its own. A developer who makes 3,000 commits over five years tells you something different than a developer who made 3,000 commits in two months and then stopped. Both profiles show the same number.

What you want to see is sustained activity on meaningful work over time. Not necessarily daily commits (that's not a realistic expectation for anyone with a full-time job), but a pattern of showing up to a project repeatedly over months or years. That kind of consistency is hard to fake and genuinely predictive.

Look at the shape of the activity graph, but don't over-index on gaps. Engineers take breaks. They switch companies. They have kids. A six-month gap in contributions doesn't mean someone got worse at their job. What matters is whether they came back.

Pull requests, not just commits

Commits are usually private. A developer pushing code to their employer's repos won't show that activity on their public GitHub profile at all. This is one reason raw commit counts mislead you: they systematically undercount engineers who spend most of their time on private enterprise codebases.

Pull requests to public projects are different. Opening a PR to someone else's repo means you understand the codebase well enough to contribute to it, you can communicate a change to maintainers you've never met, and you can handle code review feedback in front of other people. These are soft skills with a paper trail.

Look at the PR descriptions, too. A good engineer writes descriptions that explain why, not just what. "Fix bug in auth handler" tells you nothing. "Fix race condition in session refresh when concurrent requests hit token expiry within 50ms of each other" tells you the person understands their own code and assumes the reader doesn't.

Code review comments as a hiring signal most people miss

This one is almost entirely overlooked. When a developer leaves code review comments on other people's PRs, those comments are public on GitHub. Go read them.

Are the comments substantive? Do they catch real issues, or are they just "+1" and "LGTM"? Do they explain the reasoning behind a suggestion, or just issue directives? Is the tone collaborative or adversarial?

A developer who writes code review comments like "this will break under load because [specific reason]" and then follows up with a suggested fix is someone who can work on a team, communicate technical reasoning, and invest in other people's code quality. That's harder to assess in an interview than most people realize.

This data has existed on GitHub for years. Almost no one looks at it during candidate evaluation.

What deletion commits actually mean

I keep coming back to that example at the top: 1,200 lines added, 900 deleted. There's a class of developer who has the confidence and judgment to remove code rather than pile on top of it. Deletion is underrated as a skill. It requires understanding what a system does well enough to know what's actually needed, and the courage to argue for removing things that probably took someone significant time to write.

When you're reviewing a candidate's contribution history, look for commits where the diff is negative, where they took out more than they added. Look for refactoring PRs, documentation cleanups, test coverage additions. These are unglamorous contributions that experienced engineers prioritize and junior engineers often skip.

The ratio of "adding features" to "improving what's already there" tells you something real about engineering maturity.

Stars are a popularity contest

GitHub stars measure discoverability and social proof, not code quality. A well-marketed side project with a good README can accumulate stars without the underlying code being particularly good. A critical infrastructure library used by 40% of Fortune 500 companies might have 200 stars because it's boring and its users don't tweet about it.

riem.ai calls this the "underrated" problem: engineers with high-quality contributions and low social visibility get systematically overlooked because most sourcing tools surface popularity metrics as proxies for skill. The developer maintaining unglamorous but critical code, the one doing the real work that nobody posts about, is often exactly the hire that makes a difference.

When I'm evaluating someone on GitHub, I actively discount high star counts unless the project is genuinely interesting technically. And I look harder at profiles that look quiet on the surface but have years of thoughtful contributions scattered across other people's repos.

Breadth vs. depth, and what each signals

Some engineers contribute broadly across many repos, others go deep on a few. Neither is inherently better. What you want depends on the role.

A developer with deep contributions to two or three specific projects over years is likely an expert in that domain who can work sustainably on complex systems. A good example: someone who's been contributing to PostgreSQL extensions or a specific Kubernetes controller for three years probably knows that problem space cold. They may not adapt quickly to a new stack, but they'll own what they own completely.

A developer with contributions spread across 40 repos over the same period is probably a generalist who moves fast, learns quickly, and gets bored easily. Good for early-stage engineering, potentially a flight risk once the problem space gets narrower.

The breadth/depth profile is information about what kind of problem they'll thrive on. Which is exactly what you should be evaluating.

What GitHub can't tell you

GitHub contribution history is strong signal for some things and almost no signal for others.

It can't tell you how someone performs under deadline pressure. It can't tell you how they handle disagreement with a tech lead. It can't tell you whether they can explain technical tradeoffs to a non-technical stakeholder. It tells you almost nothing about people management capability.

GitHub also tells you very little about engineers who've spent their careers primarily in enterprise environments, valuable contributors who've done excellent work entirely on private codebases. A strong candidate with a thin public profile might have a decade of excellent work you simply can't see.

Tools like riem.ai try to address part of this by analyzing contribution signals across available data and triangulating from what's public. But the honest answer is that GitHub is one signal, not a complete picture. Use it as a strong prior that you then test in conversation.

A practical approach to profile evaluation

When I look at a candidate's GitHub, I run through roughly this sequence: recent activity and consistency first, PR descriptions and code review comments second, then commit/deletion ratio, then language and stack breadth relative to what the role needs, and finally stars — almost as an afterthought.

I'd rather spend twenty minutes reading someone's PR history than thirty seconds counting their stars. One tells me how they work. The other tells me whether their side project got picked up on Hacker News.

GitHub now tracks nearly 1 billion commits pushed annually across 180 million developers. The signal is in there. You just have to look at the right parts of it.

The infrastructure startup from the opening story? She's still there, two years later, and she's since hired three engineers herself, all sourced from open source contribution history, none of them with impressive follower counts.