How do you tell if a developer is actually senior from their GitHub profile?

A recruiter was searching GitHub for backend engineers last fall. She found a profile with 43 followers, no pinned repositories, and a contribution graph that was sparse, maybe three squares a week, clustered around the same two months each year. She almost moved on. Then she clicked into the pull requests.

Every PR this engineer had submitted to a major infrastructure project included a section called "Why this approach": a description of the reasoning, the alternatives she'd considered, the trade-offs she'd weighed, and links to relevant RFC discussions. Her review comments on other people's PRs ran to paragraphs. Questions about failure modes, architectural trade-offs, about why this approach held up better than the obvious alternative. "Have you thought about what happens to this under write amplification at scale? This pattern worked well in the [previous project] context but I'm not sure it holds here."

She reached out. He'd been in the same job for six years, not actively looking, and had never thought to update his LinkedIn. Three weeks later he was interviewing.

The contribution graph told you almost nothing. The PR trail told you everything.

Why does GitHub seniority assessment matter right now?

Senior engineering roles now make up more than half of all open positions in tech (an inversion from three years ago, when junior and mid-level roles formed the base of the hiring pyramid), according to Second Talent's 2026 engineering talent shortage analysis. The entry-level market has collapsed: junior hiring at large tech companies fell from 32% of new hires in 2019 to just 7% in 2026, per analysis from byteiota and Stanford's Digital Economy Lab.

The result is a market where companies are competing hard for a small pool of experienced engineers, and the engineers in that pool mostly aren't posting resumes. According to Stack Overflow's 2024 Developer Survey, 67% of senior engineers receive multiple job offers before their resume ever hits a job board. They get found through referral, GitHub, or conference talks, or they don't get hired at all.

If your sourcing workflow depends on inbound applications, you're competing for the 33%.

Why is the contribution graph the wrong place to start?

GitHub reached 120 million developers by early 2026, according to the GitHub Octoverse. At that scale, contribution graphs are almost meaningless as a seniority signal. Junior developers learning in public, engineers working on side projects, and bootcamp graduates building portfolios all produce dense green graphs. Senior engineers at companies are mostly committing to private repositories, sitting in design reviews, and doing the work that doesn't show up publicly.

The engineers with the greenest graphs are often the most junior. The engineers with the sparsest graphs sometimes have the deepest impact.

What you actually want to look at is the quality of public contributions when they do exist. (For a broader overview, see our complete guide to using GitHub for recruiting.) Four signals in particular separate senior engineers from junior ones.

What does a senior engineer's pull request actually look like?

Pull request descriptions are the single most information-dense part of a GitHub profile. A junior developer submits a PR that says "Fix null pointer exception in auth flow." A senior engineer submits a PR that explains what caused the null pointer, why this fix addresses the root cause rather than the symptom, what alternatives were considered, and what edge cases to watch in production.

The difference is a thinking style, not a preference for wordiness. Engineers who write PR descriptions that explain reasoning have internalized that code is communication. That kind of documentation behavior is almost never taught formally; it develops through years of having your PRs reviewed and learning what reviewers actually need.

Pull request volumes on GitHub jumped 40% year-over-year in 2025 but merge rates actually declined, according to Pullflow's Open Source Collaboration Report. Reviewers are doing more filtering, more back-and-forth, investing more scrutiny per merge. The engineers whose PRs move quickly through review are the ones who anticipated the questions.

How do code review comments reveal engineering experience?

If you want to understand a developer's depth, read the comments they leave on other people's pull requests. This is the signal most recruiters skip entirely because it requires clicking away from the profile itself. (We cover additional commit history signals in a separate deep dive.)

Junior engineers leave comments like: "This looks good," "Minor nit: line 47 could use a more descriptive variable name," or nothing at all. Senior engineers leave comments that reveal what they're worried about at a system level: failure modes, performance under load, the interaction between this change and a subsystem the author didn't think to mention.

Look for three things in review comments: whether they explain why something is a problem rather than just flagging it, whether they ask questions that show awareness of adjacent systems, and whether they distinguish between "you should change this" and "I'm curious whether you've thought about this."

According to LinearB's 2025 Engineering Benchmarks, top-performing engineering organizations average 1.1 review cycles per pull request, a sign that PRs are well-prepared and reviewers are decisive. The engineers driving those metrics are usually senior, and you can often identify them by looking at who is consistently the reviewer rather than the author in a well-run open source project.

What does cross-repository contribution signal about seniority?

Look at how many different codebases an engineer contributes to beyond their own projects. Junior developers almost exclusively commit to repositories they created or control. Senior engineers contribute to other people's projects: fixing a bug they found while using a library, improving docs on a framework they rely on, submitting a feature to an upstream project rather than maintaining a private fork.

Cross-repo contributions require understanding an unfamiliar codebase quickly, working within someone else's architectural conventions, and navigating a review process where you have no relationship with the maintainer. That's a specific kind of engineering maturity that shows up clearly in GitHub activity.

GitHub saw nearly 1 billion commits in 2025, up 25% year-over-year (GitHub Octoverse 2025). Most of that volume is internal project work. The subset of engineers contributing meaningfully across multiple unrelated external repositories is small, and disproportionately senior.

riem.ai surfaces exactly this pattern by analyzing 30M+ GitHub events to identify engineers with consistent cross-repo contributions, flagging profiles that would look unremarkable on the surface but show deep engagement across the ecosystem.

What do deletion commits tell you about engineering judgment?

One of the clearest signals of engineering experience is willingness to delete code. Look at commits where the line count removed is larger than the line count added. These "subtraction commits" (removing a feature, consolidating duplicate logic, eliminating an abstraction layer that wasn't earning its complexity) indicate an engineer who thinks about the long-term health of a codebase rather than just shipping features.

Junior engineers almost never delete code voluntarily. It feels risky, and there's less immediate reward for it. Senior engineers know that the most dangerous thing in a codebase is code that nobody understands anymore.

This has gotten more important as AI-generated code has introduced a new quality problem. According to CodeRabbit's 2025 State of AI Code Generation report, AI-assisted pull requests produce 1.7 times more code issues on average, with readability problems appearing at more than triple the human rate. The engineers who can identify and clean up that kind of accumulation (who see a 400-line AI-generated function and recognize it should be 80 lines) are senior, and their deletion commits will show it.

What about engineers who are senior but have almost no public activity?

This is the hardest case and also the most common. Many strong senior engineers spend most of their working life in private repositories at companies, contribute nothing publicly, and have GitHub profiles that look empty.

For these engineers, the signals shift. Look at the quality of any public interaction at all: a single issue comment, a merged PR from three years ago, a fork with a meaningful commit on top of it. Even minimal public activity, when it exists, tends to reflect the quality of thinking these engineers apply in their day jobs.

87% of organizations are already experiencing or expect an imminent talent gap in engineering, according to fullscale.io's 2026 developer hiring trends analysis. The engineers who can fill those senior gaps are not posting on job boards. Finding them requires either referral networks, or the kind of systematic signal analysis across GitHub event data that most manual sourcing workflows can't do at scale.

The recruiter who found her backend engineer didn't have a special search technique. She had patience and knew which signals to look for. At scale, that patience needs tooling.

Senior engineers don't announce themselves. They leave a trail.