Fixing the coding part of interviews

Coding interviews suck. They’re painful for everyone. But we need to assess technical ability, so we keep doing that.

What if there were a better way?

How we got here

If you’re a programmer, there’s a 99% chance you’ve been in this part of an interview:

“Okay, so, you’ve got to program a remote control for a TV. Write out the code and talk me through the solution.”

Then they open a blank tab in a text editor[1]. And…go!

This sucks. People panic. It’s hard to remember syntax or recall function names. It’s hard to map out a solution. The interviewer squirms because they KNOW the answer it’s so EASY why are you not getting it!? The interviewee feels like an idiot, or worse, wastes months memorizing the code for inverting a B-tree[2].

The worst part? It doesn’t actually assess how productive that person will be. It tells you nothing except how that person behaves in unreasonable situations.

How we actually code

That’s not how humans write code these days. Code is too complicated to write on a whiteboard. We have special-purpose software that enables us to write code faster, smarter, and more productively every day. I have four linters keeping me honest with every keystroke, and two machine-learning systems supplying me with code constructs, so I can focus on the part that needs actual human intervention.

It’s also not how teams produce code. If you go off and sit in a blank room and write a block of code and then pretend you’re done, you’re going to have a lot of trouble when you need to be a part of a team of more than one person. Software development includes division of labor, testing, usability input, data generation, version control, code and solution reviews, and a dozen other practices that ensure we ship quality products.

As someone who runs a lot of interviews, I wanted something different.

I wanted something that would tell me that this person would be a valuable addition to a programming team I was on. The qualities I look for in teammates include:

• knowledge and learning potential
• adaptability to new situations, even if it takes a minute
• working well with others, including critiquing and improving each others’ work
• finding and explaining the root cause of problems
• coming up with solutions for problems
• explaining why something is or is not a good solution in context

Of these, whiteboard coding covered maybe one and a half. No wonder it felt so wrong and artificial!

The Solution: Other People’s Code

My variant on Jakob’s Law states “Programmers spend most of their time looking at code other than their own.”[3]

So let’s do that in the code interview.

My code interview consists of three parts:

1. You are given a short block of code in your preferred language, and a series of tests for it.
2. Some of the tests are failing. There is also a note from the code’s author, who is on vacation this week, sorry.
3. I ask you to talk through the code and explain what you see, including why the tests are failing.
4. I ask you to talk through solutions for making the code behave correctly and the tests pass. This might be improvements to the code, fixing the tests, dusting off and nuking from orbit, whatever.

This tells me a lot of things about the candidate:

• Can they understand the code? Can they explain it to me? Do they understand what parts are important and what parts are boilerplate? Do they make use of all available info (e.g.: code, comments, API documentation, etc., etc.)
• Can they see the flaws? How quickly do they find them, and what methods do they use to find them?
• Can they explain the behavior in human terms, and hypothesize what’s causing any problems?
• Can they come up with plausible solutions, and explain to me why those solutions are appropriate?
• Can they critique code in a way that will make the original coder comfortable enough to accept the input and improve the work?

Usually by the end of this segment I have a much clearer idea of what kind of a team member the candidate will be.

It’s worked so far, and a nice bonus is that interviewees report less stress and more engagement afterwards.

Summary

tl;dr: Interview using code reviews, not blank-board coding. It is more true to life, and tells you much more about how the candidate will perform in day-to-day work.

It also is much less likely to piss off senior devs who have had quite enough of coding game “guess what I’m thinking” interviews. For folks with more experience, I will choose one of the more complicated code samples to review, but even with a trivial example, you’ll learn a LOT.

So try it! And tell me how it goes!

NOTE: Opinions expressed here are my personal opinions, and not intended to represent the views of any current or past employer.

Footnotes

[1] Or, if you’re interviewing in the stone age, they hand you a whiteboard marker. Because that’s how I write all my code![4]

[2] I have been paid for programming for 30 years. I have never been asked to write such an algorithm, because it is already written in every language I use, and the right approach is to import the appropriate function from the b-tree package, not to reinvent it.

Also, yes, I know inverting a B-tree isn’t a thing. I put that in there just for you! Please don’t ask “gotcha” questions in your interviews, either.

[3] This is absolutely true in industry. The main places it isn’t true are (a) in college, where you’re asked to write a lot of code from scratch, and (b) for self-taught folks[5] who learned to code before the internet was much of a thing.

[4] I’m not knocking white boards. But I don’t write code on them. I write diagrams that explain code, and the people I’m doing it with also have the context I had.

[5] But even I had some sample code to learn from, and that was a long time ago.