Innovative Interviews: The Case for Code Review Assessments
Written on
Chapter 1: A New Approach to Technical Interviews
In anticipation of my first technical interview this year, I engaged in the usual preparation by tackling various problems on Leetcode. To my surprise, the interviewer informed me that writing code was off the table; instead, I would be evaluating a pull request (PR). Initially relieved at not having to rush through coding tasks, I soon found myself intrigued by the prospect of analyzing someone else's code—a task I genuinely enjoy. This experience illustrated how a technical interview should evoke excitement and engagement.
This was a different kind of interview.
My interviewer provided a link to a PR and asked me to read the description, sharing my thoughts on the proposed changes. I inquired whether I should save my suggestions until after reviewing or discuss my thoughts as I progressed. He preferred the latter, which suited my style perfectly as it encouraged a natural flow to the conversation.
I began reading the description aloud, articulating my expectations for the changes. I wanted to ensure that my thoughts aligned with what I encountered in the code. I discovered that there was only one file to review, which made the task feel manageable.
After analyzing the initial lines, I returned to the PR description to confirm that the changes met their intended goals. Overall, they did, though a few issues could lead to potential bugs. I pointed out these concerns and offered suggestions for improvement, which my interviewer acknowledged, allowing me to continue exploring.
Rather than trying to optimize every single line of code, I noted when the existing approach sufficed, even if it didn't feel perfect. Although I sensed that some elements needed adjustments, I wasn't entirely certain why. Fortunately, my interviewer remained patient, encouraging my curiosity.
"This looks acceptable," I concluded.
He prompted me to consider edge cases, leading me to realize potential issues. "We could approach that in two ways," I suggested. At times, he would provide no feedback, and simply stating that something looked fine was an acceptable response.
"You overlooked this line," he pointed out, inquiring about a specific tool used in the code.
I admitted my unfamiliarity, worrying that I might be penalized for not knowing. However, he reassured me, stating that only a small percentage of engineers employed that tool, and he took the time to explain it, asking questions to ensure my understanding. This experience made me feel appreciated and focused on an in-depth exploration of the code rather than judgment.
Section 1.1: Traditional Interviews vs. Code Review Assessments
In my previous technical interviews, the primary focus often seemed to be passing test cases. I distinctly remember the pressure of watching the countdown timer while attempting to debug a series of print statements or frantically searching for ways to optimize my code to meet speed requirements.
While some of these interviews were undoubtedly engaging, they rarely allowed me to concentrate on creating extensible and adaptable code. It’s possible that I may be a slower problem-solver, while others manage to solve and refine multiple challenges within a limited timeframe.
However, many candidates likely share the desire for a more measured pace during interviews. This inclination isn't necessarily negative. With a growing focus on mental well-being post-pandemic, studies indicate that software engineers experience burnout at higher rates than other professions. Perhaps we can address this issue through our interview processes. If we want candidates to think critically without the pressure of a ticking clock, then code reviews may be the ideal solution.
I had half an hour to assess 27 lines of code, which felt relaxed and meaningful. This timeframe allowed me to carefully consider design choices and express my opinions.
Section 1.2: The Value of Collaboration in Interviews
Consider the typical technical interview scenario: you might collaborate with a company engineer, explaining your code as you work through it, or you might complete an assessment independently. While there may be minimal collaboration, it seems counterintuitive since the interviewer represents the company. If they show genuine interest in your thought process, it’s a reflection of the company culture.
My experience conducting a PR review with another engineer was collaborative in nature. Beyond discussing edge cases, the interview required me to:
- Understand another engineer's problem-solving approach rather than solely focusing on my own.
- Recognize the strengths in someone else's work.
- Provide constructive feedback.
Such collaboration is rarely present when tackling problems like constructing a Caesar cipher or transposing a matrix, which I encountered in past interviews.
Chapter 2: Characteristics of Effective PR Reviews
The first video titled "Code Review Tips (How I Review Code as a Staff Software Engineer)" discusses essential techniques and strategies for conducting effective code reviews.
As I reviewed a file with 27 lines, I appreciated having sufficient time to discuss each line thoroughly. This approach emphasized the quality of the code. However, since individuals think at varying speeds, the time allocated might need adjustment based on the PR's complexity and the company's expectations.
Ultimately, the content of the PR should hold greater importance than the time constraints. Based on my interview, effective PRs should include:
- Code Changes: A clear distinction between code that requires modification and that which does not. For instance, if a company, AwesomePetTracker, needs a Dog class with specific properties, the PR should correctly define these attributes.
- Edge Case Consideration: The PR should also prompt discussions about potential edge cases. For example, if the description indicates that every dog must have a fur color, the interviewer might ask how to handle hairless breeds like Xolos.
- Variety of Concepts: The PR should incorporate both basic and advanced programming concepts. Starting with familiar elements allows candidates to build confidence before tackling more intricate topics.
Conclusion: Rethinking the Technical Interview Landscape
While I’m not an interview designer, my insights stem from personal experiences. I appreciated the technical interview format centered on code reviews and envision how these reviews can be structured.
Traditional technical interviews still hold value, pushing candidates to think strategically. They also provide opportunities to showcase interpersonal skills. However, I firmly believe that incorporating PR reviews offers a compelling alternative. Perhaps companies could replace one technical interview with a code review.
What are your thoughts?
Thank you for reading!
P.S. If you found this article insightful, please consider following me. Your support means a great deal as I navigate my journey as a student.
The second video titled "Code Review Best Practices For Software Engineers" explores effective strategies and guidelines for conducting code reviews that enhance teamwork and code quality.