Code Review Doesn't Show Up on Your CV (I Fixed That)

Here's a thing that bugs me about how we measure engineering output.

A junior engineer who commits 50 times in a week has a fully green GitHub contribution graph. A staff engineer who spends most of that week reviewing those 50 commits, leaving detailed feedback, approving 12 PRs, and blocking 3 for rework? Their graph looks like they did nothing.

This isn't an obscure edge case. It's what senior IC work actually looks like at most companies above a certain size. The ratio shifts. You write less, you review more, you make the code around you better. And that work is invisible to anyone looking at your GitHub profile.

I've been building EverCV for a few months now — a system that automatically updates your CV from your actual work signals. Commits, merged PRs, tickets, deployments, time entries, documentation. One signal type was conspicuously absent: the PRs you reviewed, not the ones you opened.

Tonight I added it.

The GitHub GraphQL API has a contributionsCollection.pullRequestReviewContributions query that returns exactly what I needed: every PR review you submitted in a date range. Not just "you were assigned as a reviewer" — the actual review events, with the review state (APPROVED, CHANGES_REQUESTED, COMMENTED) and the PR details.

query($login: String!, $from: DateTime!, $to: DateTime!) {
  user(login: $login) {
    contributionsCollection(from: $from, to: $to) {
      pullRequestReviewContributions(first: 100) {
        nodes {
          pullRequest {
            number
            title
            url
            repository { nameWithOwner }
          }
          pullRequestReview {
            createdAt
            state
            body
          }
        }
      }
    }
  }
}

That's the whole thing. Run it once per day per user, and you get every review they submitted.

The bucketing decision was interesting: which reviews count as "shipped"?

My answer: APPROVED reviews. When you approve a PR, you're the last gate before that code goes to production. You're exercising your technical judgment and putting your name on the outcome. That's a shipped contribution — you enabled the ship, even if you didn't write the code.

CHANGES_REQUESTED and COMMENTED reviews are "in flight" — you're participating in the work but it hasn't landed yet.

The resulting CV signal for a heavy review day looks like:

GitHub PR Reviews — Approved 4 PRs across 3 repos (acme/api, acme/infra, acme/cli). Changes requested on 2 PRs.

At the week level, that becomes:

Reviewed 23 PRs (14 approved, 6 changes requested, 3 commented). Primary reviewer on the authentication refactor in acme/api.

That's a CV entry. That's evidence of the kind of engineering work that makes you valuable.

The other thing I did tonight was add an insight for "heavy review days": if you review 4+ PRs in a day, EverCV surfaces a narrative fact like "Heavy review day — 8 PRs reviewed, 5 approved." This shows up in the weekly digest alongside "heavy commit day" and "cross-repo day."

The pattern is simple: collect signal at the source, bucket it, derive narratives from the aggregate. The interesting work is deciding what the narratives are. What does "good" engineering output look like in each source type? For commits it's consistency and breadth. For PRs it's merge rate and turnaround. For reviews it's volume and approval rate (a proxy for sound judgment).

There's a meta-lesson here about tools and measurement. Whatever you measure, people optimize for. GitHub's contribution graph measures commits, so people optimize for commits. A staff engineer who spends a week reviewing, mentoring, and documenting — and makes a consequential architectural decision in a 30-minute meeting — shows up as unproductive.

I'm not trying to game this with EverCV. I'm trying to capture what actually happened. Code review is real work. It should show up somewhere.

Now it does.