What is code review, and why it matters when you screen developers

Short answer: code review is the practice of one developer reading another developer's code change before it becomes part of the product. The reviewer checks for bugs, unclear logic, missing tests and design problems, then approves or asks for changes. When you screen developers, code review matters because the reviews a candidate has given show judgment, communication and seniority, and a coding test cannot show any of those.

How code review works

Most teams review code inside a pull request. The author proposes a change. One or more teammates read it and leave comments attached to specific lines. Some comments are questions ("why not reuse the existing function?"), some are requests ("this will fail if the list is empty"), some are praise or small style notes.

The author replies and updates the code. When the reviewer is satisfied, they approve it and the change is merged.

Teams do this for four reasons: to catch bugs early, to keep the code consistent, to spread knowledge so no one person is the only expert on a part of the system, and to teach junior developers.

Reviews received vs reviews given

These are two different things, and recruiters should look at both.

	Reviews received	Reviews given
What it is	Others commenting on the candidate's changes	The candidate commenting on others' changes
What it shows	How they take feedback and improve their work	How they think about quality, risk and other people's work
Strongest when	The reviewers are outsiders and the project is real	Comments are specific, kind and correct
Visible on public GitHub	Yes, for public repositories	Yes, for public repositories

Reviews received show whether someone can work with others. Reviews given go further: they show what the person notices. Spotting a problem in someone else's code takes understanding of the whole system, not only the lines on screen. Senior engineers spend a large share of their time reviewing for that reason.

Why reviews given are a strong hiring signal

They are hard to fake in a test. A coding test gives a candidate a puzzle and asks for output. A review shows reasoning about someone else's real, messy code, with no puzzle and no time limit.

They separate seniors from juniors. A junior reviewer often comments on formatting and naming. A senior reviewer asks: what happens when this fails? Does this change break something else? Is there a simpler way? Look for comments about consequences, not appearance.

They show communication. Good reviewers explain why. "This could throw if the user has no email, so I'd check first" is a useful comment. "Wrong." is not, even if the reviewer is right.

They show ownership. Someone who reviews other people's work regularly is trusted by the team. Maintainers of open source projects are often chosen for exactly this reason.

They are available when AI writes the first draft. Tools can now produce code quickly, so the scarce skill is deciding whether code is correct and fits the system. That is what a reviewer does. See how to hire developers when everyone uses AI.

What good and weak reviews look like

Strong signs

• Comments that name a specific risk and a reason
• Suggestions with an alternative, not just a complaint
• Questions that show the reviewer understood the goal ("is this meant to also handle archived users?")
• A respectful tone, including when disagreeing
• Approvals that come after real discussion, not instantly

Weak signs

• Only "LGTM" (looks good to me) with no other comment, repeatedly. It is normal occasionally and a flag as a pattern.
• Comments only about spacing, naming or style, which automated tools can check
• Harsh or personal wording
• Many approvals within seconds of the PR opening, which suggests nobody read it

What you cannot see

Be straight with yourself about the limits.

• Private repositories. Most reviews happen inside companies and never appear on a public profile. A candidate with ten years of excellent private review work can have zero public reviews.
• Team norms. Some teams review in chat or in meetings, not on GitHub.
• Volume is not quality. Fifty one-word reviews show less than three thoughtful ones.

So treat public reviews as a bonus signal, never a requirement. When a candidate has none, ask them about reviews in an interview.

A recruiter's checklist for reading code review evidence

1. Open the candidate's GitHub profile and search for pull requests they have reviewed (GitHub's search accepts reviewed-by:username).
2. Pick two or three on projects other people use.
3. Read the candidate's comments only. Ignore the code.
4. Ask for each comment: is it specific? Does it explain why? Is it kind?
5. Note one comment that shows good judgment. Bring it to the interview.

Interview questions that use review evidence

• "In your review on the X project you suggested changing how the cache was cleared. What was the risk you saw?"
• "Tell me about a review comment you gave that the author disagreed with. How did it end?"
• "What do you look for first when you open a pull request?"
• "Describe a review comment someone gave you that changed how you write code."

Listen for specifics: a real example, a trade-off, a change of mind. Generic answers ("I look for bugs and readability") are weak, but not disqualifying: many good engineers are bad at describing what they do. Follow up before deciding.

Where DevEval fits

DevEval looks at reviews a candidate gave and received on public code, reports what it found, and says plainly where the evidence is thin. It also suggests interview questions drawn from those specific reviews. The methodology page lists what it measures. A report is a starting point for a human conversation, not a replacement for one.

Frequently asked questions

Is code review the same as testing? No. Testing runs the code to see if it works. Review is a person reading it to judge whether it is right, clear and safe. Teams do both.

Do all developers do code review? Most professional teams do. Solo developers and tiny startups sometimes do not, so its absence on a profile is not a red flag.

Does a candidate need to know I looked at their reviews? Telling them is fair and courteous. Say you looked at public pull requests and reviews, and why.

Next: what a pull request is and how to screen developers without a coding test.