About the author
Adam Beaton is a senior software engineer at PullRequest. Prior to joining the team, he was a Software Development Engineer II at Amazon, senior software engineer at Mastercard, and senior software engineer at Applied Predictive Technologies.
Have you ever noticed that reviewing code is frequently a job requirement for software engineering positions? At the time of writing, I found many job postings at blue chip software companies that include code review as a responsibility:
|Software Engineer - Infrastructure||“Conduct design and code reviews”|
|Amazon||Software Development Engineer, Amazon Devices||“Solid coding practices including… peer code reviews…”|
|Netflix||Senior Software Engineer - User Systems & Data||“Have sharp attention to detail and openness to critique through code and design reviews”|
|Backend Engineer - Twitter Platform||“Familiar with standard software engineering methodology, e.g. unit testing, code reviews, design documentation”|
|Microsoft||Software Engineer||“Perform code and design reviews that guarantee code quality and that allow our more junior members to learn and grow their expertise”|
|Software Engineer - Onboarding||“Produce high quality software that is unit tested, code reviewed, and checked in regularly for continuous integration.”|
While this list is admittedly anecdotal, my hope is that it is illustrative. Hiring managers aren’t only seeking out excellent programmers. It’s not just whether you know Java or Python or SQL. Hiring managers are also looking for competent code reviewers.
And with good reason. Code reviews are an opportunity to ensure a healthy codebase and prevent bugs, all while fostering knowledge sharing and collaboration.
Yet, how many candidates truly demonstrate code review prowess, either on their resume or during the interview process? How do hiring managers determine if a candidate is a skilled reviewer?
Sure, there’s the occasional code reviewing interview, where a company prints out code on a piece of paper and asks the candidate to provide feedback. But this interview style is rare; I recall only ever participating in two code reviewing interviews. And even still, does this interview style truly simulate the day-in and day-out grind of reviewing PR after PR after PR?
In the same vein, some developers are prolific on open source projects, hoping the functionality they implement and the code that they review will bolster their resume. But in my experience, few hiring managers drill into a candidate’s github portfolio, let alone individual PRs. They aren’t evaluating review timeliness, quality, or thoroughness.
Software engineers need a way to prove succinctly and quantitatively that they have the code review skills that recruiters and hiring managers are looking for.
Demonstrating Code Review Skill with PullRequest
PullRequest doesn’t just offer a network of expert engineers who can augment existing code review processes. We’ve built a powerful platform for gathering and synthesizing code review metrics and benchmarks for each participant in the code review lifecycle. Whether that’s the reviewers in the PullRequest network or the software developers on the teams we serve, both can log into the platform and reap the rewards of these insights.
PullRequest provides benchmarks on everything from Code Review Size to Reviewer Response Latency. Armed with this data, developers can discover ways to improve their code reviewing habits and prove code review expertise. Numbers don’t lie.
Here are three examples of code review metrics PullRequest collates that help development teams hone their skills and be a killer code reviewers for their team.
Reviewer Response Latency
One metric that PullRequest aggregates and benchmarks is Reviewer Response Latency, or the average latency between when a review is opened and when feedback from a reviewer is posted. This is essentially a measure of how quickly you review your teammates’s code.
All things being equal, the faster code is reviewed the better. The longer code is out for review, the longer customers are impacted. As a rule, we want code changes and new features shipped out to production at a fast clip. Managers are looking for engineers who will help facilitate feature delivery by quickly getting to code reviews.
With the PullRequest platform, you can now prove to hiring managers that you’re responsive. On your resume, you’ll be able to make claims, such as “On average, I posted feedback to my teammate within eight hours of a pull request being opened.” Or, during interviews you can pepper your answers with these metrics. For example, “A big part of getting this feature over the line was reviewing my teammates code. Over the past month, I reviewed PullRequests within 11 hours of being opened, on average.”
As you progress into more senior engineering positions, you can use Reviewer Response Latency to understand how you influence your team’s processes and dynamics. For example, “As team lead, I was able to drive down average Reviewer Response Latency from 47 hours to 18 hours over the course of the year by instituting a new software development process.”
Issue Catch Rate
PullRequest also tracks Issue Catch Rate, or the average number of issues you and your team catch per 1000 lines of code reviewed.
Issue Catch Rate is a measure of the quality of code review feedback. At the end of the day, the goal of code review is to ensure that we safeguard our source code from bugs and defects, not to post the most comments or review the post PRs.
Imagine if you could add the following bullet to your resume: “On average, the team I led detected 5.3 issues per 1000 lines of code reviewed, 50% over the median.” Do you think that would get a hiring manager’s attention?
Issue Catch Rate helps developers know that, each time you review a code change, you are truly helping ensure code quality in the software development lifecycle. You are finding bugs before they can ever reach production.
One challenge that many teams face is that not every teammate participates in the code review process equally. Some team leads have to jump through hoops, ensuring that each person on the team is assigned a roughly equal number of code reviews and that no one is shirking their responsibilities.
Hiring managers are looking for proactive code reviewers, the ones who will roll up their sleeves and get the job done. Our platform exposes metrics like Total Code Reviews and Total Comments that can help show you are an active contributor.
Compare and contrast these two sentences on a cover letter. Rather than simply saying “I participated in my team’s code review process”, you can now say “I reviewed 204 code reviews over the past year and left 6.94 comments per review.” Similarly, as a leader in your organization, you’ll be able to measure and state impact. For example, “Over the past year, our team increased the number of comments on code reviews by 20%.”
These days, it’s not enough to be a computer science grad or a great coder. While there’s no definitive template, teams are looking for well rounded engineers, with experiences ranging from api development to test driven development. While code review is just one of many important skills, PullRequest metrics might just help you and your team stand out from the crowd.
Are You a Talented Engineer? Join Our Network!
Another great way to demonstrate code reviewing skill is to join our network! While highly selective, reviewers on the PullRequest network have an opportunity to review code for a wide variety of customers, with varying tech stacks, coding styles, preferences, and approaches.
Since we only admit 1% of applicants into our network, adding “PullRequest Code Reviewer” to your resume carries weight.