Code quality interviews
I've been through a lot of coding interviews in my life. I've had four jobs, and thus have been through the job search process four times. Each time I took the "quantity over quality" approach, and basically mass-applied to as many companies as I was able to. Maybe something like 150-200 companies each time. To a variety of web-related programming roles. From there, I'm not sure how many interviews I had each time, but it was probably something in the ballpark of "dozens".
I can think of four main categories of interview questions I've been presented with:
- Data structures and algorithms
- Real world problem solving
- Behavioral
- Domain-specific knowledge (eg. "How does prototypal inheritance work?")
A fifth category is "product thinking". Eg. "What would you do to improve this landing page?" or "What features should we add to better address customer's needs?". I've only encountered that a few times though.
A sixth category would be system design, but I've never really had one of those in an interview.
In this post, I want to talk about a seventh category: code quality interviews. By "code quality", I am roughly referring to the sorts of things that Bob Martin talks about in his book Clean Code.
Arguing that code quality is important is beyond the scope of this post. This post is intended for people who are already on the bandwagon. The questions I want to address here are:
- Is there a practical way to test candidates on their ability to write clean code?
- Is writing clean code a skill, or is it just a matter of want-to?
- Is the ability to write clean code predictive of other useful skills?
Is there a practical way to test candidates on their ability to write clean code?
I'm not sure, but here's an idea I feel pretty optimistic about: have candidates review a pull request. Let me elaborate...
Check out this clean-code-javascript repo on GitHub. It basically goes through Bob Martin's book Clean Code and gives examples of what is good and what is bad.
So, what I envision is a PR that has various "bad" examples scattered throughout, and you'd be hoping that the candidate identifies them as bad and proposes a better alternative.
That's how it'd look in broad strokes anyway. I haven't had a chance to actually put this to the test, so I expect that things would be a little rough around the edges, but overall I am optimistic.
I also think that this would serve as a great conversation starter. Hopefully it would lead to larger conversations, eg. about how side effects can be problematic, or about how following the rule of three is a good way to avoid abstracting things prematurely. If a candidate can dive into one of these conversations and speak intelligently about it, that's probably a pretty good signal.
I've actually had one interview where I did this! I thought it was fantastic! The way this one was structured, I reviewed the PR on GitHub and left comments, just like you would in real life. Then I had a Zoom call where I talked everything through with the interviewer.
Personally, I suspect that it would be a good idea to do the initial code review via a Zoom call so you can observe the candidates initial thought process, but I'm not sure. Maybe the mix of async and sync was good. After all, it can be hard to collect your thoughts and offer your best comments during the pressure of a live interview. Regardless, if the big picture I'm trying to paint is a good one, I'm sure these sorts of details can be figured out.
Let me end this section by trying to be honest about where I stand here. As I've gotten older, I've moved more and more towards being skeptical of ideas that haven't been battle tested. They look pretty at first, but when you actually put them into practice they usually start growing warts. This idea has not been battle tested, and so I (am trying to!) have a degree of skepticism about it. However, I'm also not one of those people who think ideas mean nothing. Ideas are simulations. It's hard to simulate perfectly, but that doesn't mean you can't simulate usefully. What I'm trying to say is that it's not a black or white thing, and my optimism here is perhaps a 7/10.
Is writing clean code a skill, or is it just a matter of want-to?
I have mixed feelings about this. On the one hand, given my experiences working with dozens of developers throughout my career, the idea that it is "just a matter of want-to" does not pass the smell test. There is clearly a difference in ability, and I think that most other developers would agree with this.
But on the other hand, if you're in an interview where you know you're being evaluated on your ability to write clean code, you're going to make sure you think about using good variable names, creating the right abstractions, commenting things appropriately, etc.
Here's a concrete example. I've seen people use Array.map in JavaScript before instead of Array.forEach. Eg.
users.map(user => {
api.user.update(user);
});
If they were in an interview where they are explicitly being tested on code quality, I expect that they would realize "I don't understand map too well, that might be a bad practice, let me just use forEach." But... and here's the key point... such a thing is not at the front of their minds. And in practice, when these sorts of things aren't at the front of your mind, you resort to the "bad" technique instead of the "good" one. So to some extent, interview candidates can "game the system".
But that is true of other types of interviews too! For example, if you're in an algorithms interview, you'll be laser focused on big O, whereas in real life you may not have a deep enough understanding for inefficient algorithms to "pop out" to you.
However, there is only so much that you can fake in an interview. If you don't know what a priority queue is, you don't know what a priority queue is. And, circling back to code quality interviews, if you don't realize that functions should only be one level of abstraction, that's not the kind of thing that you can sidestep.
So then, the question becomes, to what extent can you sidestep in code quality interviews? Like always, reality isn't black or white, and the difficulty is finding the right point on the spectrum. That's a difficult thing to do here though. I guess I'll just say that I personally suspect that it'd be something like a 6 or 7 out of 10, where a 10/10 is "impossible to sidestep". I wish I could do better than just offering my opinion, but it's a hard thing to dive deeper into, and my goal in this post is really just to be posing questions.
Is the ability to write clean code predictive of other useful skills?
Algorithms questions are really divisive. One camp says that they're stupid and you never have to do that sort of stuff in the real world. A second camp says that you do. But then, a third camp admits that you don't, and instead, argues that such interview questions identify candidates with a high aptitude, and say that if the candidates can understand such complicated algorithms, they're going to be able to learn all of the other things as well.
Personally I have a pretty big heap of skepticism for the third camp, but let's not talk about that here. Instead, let's talk about whether code quality interviews have the same benefit.
I don't think they are (too) predictive of that sort of high IQ aptitude that algorithms questions try to get at. But I do suspect that they'd be predictive of someone who has a talent for communication. The ability to express oneself clearly, and for that matter, the ability to think clearly about a problem in the first place. Like everything else in this article, I don't say this with a high degree of confidence, but it is something I feel optimistic about. Food for thought.
If you have any thoughts, I'd love to discuss them over email: adamzerner@protonmail.com.
If you'd like to subscribe, you can do so via email or RSS feed.