A Code Review, also sometimes called a "Peer Code Review," is the software engineering process that involves 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.
It's a practice that will likely come up, in some form or another, during your software engineer interview. There are many different tools or methods certain companies use for code reviews. However, SWE candidates need to understand the concept of the process itself.
How does this relate to software engineering 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 that you'll be asked to complete before your on-site interviews. Some interviews even give candidates the option of conducting 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. 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
First and foremost, candidates should evaluate the design of the changelist being reviewed. Be sure to ask yourself some questions such as: 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?
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?
In many cases, the changelists to be 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. Either way, if you're a candidate performing a code review, you should always investigate any edge cases that may affect the code. Concurrency problems are another major functionality problem 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, it may be prudent to validate the changelist being reviewed. This is especially true when considering UI changes or something similar that immediately affects end-users. However, this will likely be unnecessary for the code review assignments for software engineering or engineering management interviews.
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 should. The greater the complexity, the greater the potential for problems or bugs. While conducting your code review, you should evaluate every single line regarding its complexity. Always ask yourself: is this line too complicated, is this class too convoluted? Is this function more elaborate than necessary?
When judging the complexity of the changelist, you should simply think about whether this code can be understood quickly by other developers reading it. If not, chances are it is more complicated than it should be. The reason that this is so important is that if code is difficult for developers to understand, it is likely that they will make changes that result in bugs down the line.
One overlooked aspect of a code review tends to be the general consistency of the code with the rest of the software at large. Truth be told, this may be a more challenging aspect of a code review compared to the other sections in our list. Chances are, however, that an engineering style guide of some sort will be available to you that is specific to the company.
Finally, candidates conducting a code review should look to and evaluate the comments that were left by the developer. Well-written code should always come alongside well-written comments. Therefore, you should be asking 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 certain lines of code exist rather than what the code is doing. Going back to the complexity of the code, comments that explain what code is doing should not be necessary. The code should be easy enough to understand on its own. Otherwise, it is likely that it should and can be simpler. Keep in mind that this is not a black and white rule. There are times where 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 aspects of code that you can quickly scan over, such as data files or large data structures. However, you should carefully evaluate every line of code written by a developer, whether they be classes, functions, etc.
Ultimately, 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 these comments that 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. One rule of thumb is to keep all your comments focused on the code itself without any comments directed towards the developer. It may feel difficult enough for some people to have their work criticized, 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. It's not always necessary to provide a long or drawn-out explanation of every comment or suggestion. 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 for several important reasons. Just because they often take the form of take-home assignments does not mean that 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 that to a hiring manager.
- Code reviews are usually critical aspects of a company's development process. Code reviews are common practice in software engineering. This is especially true at larger companies with huge code bases. As such, hiring managers need to know that their candidates are capable of 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 not written by yourself, code reviews provide the chance 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 on past SWE interview questions
📖 Study our Software Engineering company interview guides
👯♂️ Practice your behavioral and system design skills with our mock interview practice tool.
👨🎓 Take our complete Software Engineering interview course.