How to Ace a Code Review Interview

A Code Review, or "Peer Code Review," is a software engineering process involving developers looking over code for mistakes or other problems. In many instances, code reviews involve many different developers working together.

The process is a cornerstone of producing good software, no matter the company. After all, code is written by human beings, and, unfortunately, nobody's perfect.

Mistakes, one way or another, will be made. Fortunately, these mistakes can be caught and fixed efficiently through systematic code reviews.

In many cases, software engineering candidates will need to answer code review interview questions. There are many different tools or methods certain companies use for code reviews.

First, however, software engineering candidates need to understand the concept of the process itself.

Code Reviews and Software Engineer Interviews

In some software engineering or engineering management interviews, your hiring manager may ask you to perform a code review project.

In many cases, this will be a take-home assignment you'll need to complete before your on-site interviews.

Some interviews even allow candidates to conduct a code review instead of a coding interview round. However, this is usually more common during engineering manager interviews.

There's a lot that goes into effective code reviews. Even so, preparing for them may feel overwhelming if you haven't had that much experience doing them first-hand.

That's why we cover all the fundamentals of effective code reviews in our guide here.

Let's get to it!

What Candidates Should Look For During Code Reviews

Code Design

First and foremost, candidates should evaluate the design of the changelist being reviewed.

Be sure to ask yourself questions like:

• Do the individual pieces of code in the changelist make sense together?
• Are suggested changes better served for the codebase or a library?
• Does the changelist function well with the system at large?
• Is this an appropriate time to add the functionality in question?

Code Functionality

Secondly, the functionality of the changelist is a crucial aspect to be evaluated during a code review.

Ask yourself:

• Does the changelist actually perform the functions it is meant to?
• Is the intended function beneficial for both the end-users and the developers working with this code?

Most of the time, the changelists being reviewed should generally work well enough at that stage. However, this is not always the case and may intentionally not be the case if a code review is designed for an interview.

If a candidate performs a code review, they should always investigate any edge cases that may affect the code. For example, concurrency problems are major functionality problems to look out for.

At the end of the day, the best frame of mind for this aspect of the code review is to put yourself in the users' shoes. This means both the end-users and the developers who will later work on this code.

Outside of interviews, validating the changelist may be prudent. This is especially true when considering UI changes or something similar that immediately affects end-users.

Nevertheless, this will likely be unnecessary for the code review assignments for software engineering or engineering management interviews.

Code Complexity

Besides the functionality of the changelist, the next most important thing to consider is the complexity of the code being reviewed.

Ultimately, the changelist should not be any more complex than it has to be. The greater the complexity, the greater the potential for problems or bugs.

While conducting your code review, you should evaluate the complexity of every single line of code.

Always ask yourself:

• Is this line too complicated?
• Is this class too convoluted?
• Is this function more elaborate than necessary?

The best way to judge the complexity of the changelist is by thinking about whether the code can be understood quickly by other developers reading it.

If not, chances are it is more complicated than it should be.

This is so important because if code is too complicated for developers to understand, it is likely that they will make changes that result in bugs down the line.

Code Consistency

One overlooked aspect of a code review tends to be the general consistency of the code with the rest of the software at large.

This may be a more challenging aspect of a code review compared to the other sections in our list.

Chances are, an engineering style guide of some sort will be available to you that is specific to the company that will be handy for this part of the code review.

Comments

Finally, candidates conducting a code review should look at and evaluate the comments left by the developer. Well-written code should always come alongside well-written comments.

Therefore, you should ask yourself:

• Are these comments easy to understand?
• Are these comments necessary to read the code?
• Do these comments provide meaningful explanations of the developer's thinking?

A good rule of thumb is that well-written comments should explain why particular lines of code exist rather than what the code is doing.

Going back to the code's complexity, comments explaining what the code is doing shouldn't be necessary.

The code should be easy enough to understand on its own. Otherwise, it can likely and should be more straightforward.

Keep in mind that this is not a black-and-white rule. There are times when intricate algorithms, for example, can be explained with comments.

Nevertheless, the comments left by the developer should generally elucidate the decisions they made in writing the code.

Evaluate Every Line Assigned

Last but not least, you should strive to look at every line of code under review.

This may seem obvious, but sometimes it may be tempting to skip some seemingly unimportant lines of code if the code review is of a larger scope.

There are certain parts of the code that you can quickly scan over, such as data files or large data structures.

However, you should carefully evaluate every line of code a developer writes, whether they be classes, functions, etc. Of course, you should look for and spot general coding errors and broken code.

Still, not every line of code requires the same level of scrutiny.

Some blocks of code may need more work than others.

Making these decisions is simply part of performing a code review. It is up to the individual judgment of the reviewer.

Best Way to Write Comments During a Code Review

When conducting code reviews, you'll undoubtedly be making dozens of comments.

During your interview assessments, your hiring managers may scrutinize the scope and style of the comments you leave.

Luckily for you, there's an easy way to write code review comments effectively:

Always Be Respectful

You need to always keep in mind that code reviews essentially are critiques of another developer's work.

This means that, first and foremost, you should always remain courteous and respectful when making comments.

Try to keep all your comments focused on the code itself without any comments directed towards the developer themselves.

Of course, some people may not be receptive to critiques of their work, but a personal attack gets nobody anywhere.

This, unfortunately, may not always be possible, but something you should always keep in mind.

Always Provide Explanations

Great comments always have something in common. That is, they always provide explanations for their reasoning.

This not only helps keep the comments respectful and productive but, needless to say, helps the developer understand the suggestion better.

But, of course, providing a long or drawn-out explanation of every comment or suggestion is not always necessary.

Yet, there are many times it is beneficial to explain your reasoning. This is especially true of code review interview rounds, as you can imagine.

Why Hiring Managers Care About Code Reviews

At the end of the day, there are several reasons hiring managers ask engineering candidates to perform code reviews.

First, just because they often take the form of take-home assignments does not mean they do not reveal important information about your potential as an engineer.

Hiring managers care about code reviews because:

• Code reviews help weed out unqualified candidates. Before they go through the trouble of interviewing unqualified engineers, a take-home code review assignment can demonstrate this to a hiring manager.
• Code reviews are usually critical aspects of a company's development process. Code reviews are standard practice in software engineering. This is especially true at larger companies with massive code bases. As such, hiring managers need to know that their candidates can perform them, as they will most likely be a part of their development duties.
• Code reviews give candidates to demonstrate their engineering skills. Code review assignments can be great opportunities for engineering candidates to show off their chops. Considering you would be reviewing code not written by yourself, code reviews allow you to demonstrate another unique dimension of your engineering abilities.

Additional Software Engineering Interview Prep

There's a lot more to software engineering interviews than code reviews. That goes without saying. This means that you will need some additional resources to prepare you for your software engineering interviews!

Luckily, at Exponent, you will find everything you could need to ace your upcoming software engineering interview.

💬 Review previously asked software engineering interview questions

📖 Study our company-specific software engineer interview guides

👯‍♂️ Practice your behavioral and system design skills with our mock interview practice tool.

👨‍🎓 Take our complete Software Engineering interview course.