Problem

Technical interviews for software developers usually include one or more of the following screens:

  • Coding challenges/take-home projects/personal projects
    • Tests how a candidate codes
  • System architecture questions
    • Tests whether a candidate understands how systems work
  • Data structure & algorithm questions
    • Tests for CS fundamentals

While all of these do a good job at testing different areas, there is one skill that they don’t test for: reading other people’s code.

This is arguably one of the most important skills a developer can have, yet it’s rarely tested for. People assume that all code is equally legible and developers can understand all of it at any time.

Solution

To solve for this, I’ve been trying out code review interviews. They go something like this:

  • Pre-interview
    • Find an open-source project that uses the tech I want to screen for
    • Get familiar with the project, which includes:
      • In-depth code dive
      • Running it locally and demoing it
    • Clone the repo
    • Wipe the git history and re-initialize it
    • Delete any breadcrumbs that could lead back to the source (README, links, etc.)
    • Re-upload the repo somewhere
  • Interview
    • Ask candidate to share their screen
    • Send them the link to the repo and begin the code review

Since you don’t know what you don’t know, the code review should be open-ended, meaning the candidate should be allowed to do anything they want. However, since interviews are time-constrained, it’s good to give them a short checklist, so that they have a clear goal in mind as well. I’ll usually ask them to answer the following:

  • What does the code/app do?
  • How would you make it better?

Screen-sharing is important because it gives you insight into how the candidate processes and researches new information. It’s also important to engage with them so that they talk about what they’re thinking.

Motivation

Originally, I would ask candidates to share a personal project of theirs and explain what it was and how it worked.

This would test for the candidate’s ability to code, but I ran into a common hurdle: most candidates didn’t have any personal projects that were interview-worthy, if any at all.

This is reasonable, since most developers don’t spend every waking moment of their lives coding. You can’t ask them to share their past employer’s code either.

Eventually, I would just share my screen and go to some open-source Rails/React project and ask the candidate to explain the code, which was where I got the idea to do code reviews.

Curating Projects

Since the project curation process is time-consuming, you should do it long before you even begin interviewing. Ideally, you should have a collection of projects that you use across interviews.

However, you need to come up with a good collection that ranges in difficulty and breadth, so you can screen for candidates of various experience levels and roles.

It’s good to scout out new projects from time to time and add them to your collection.

What about writing code?

Code reviews can still give you insight into how a candidate writes code by asking them how they would structure the code differently, or if they make comments about how the code isn’t the way they like it.

If it’s important to you that you see written code, you can schedule multiple technical interviews. However, if you find yourself in a fast-moving environment, I’d usually take a leap of faith and assume that a person’s code-reading abilities are correlated with their code-writing abilities.

Summary

Code review interviews kill many birds with one stone. They allow you to screen a candidate’s software, reading and researching skills in one go. Try out a code review at your next interview!