In Defense of Whiteboard Coding

Recently, I've been involved with some discussions around replacing LinkedIn's 'traditional' whiteboard coding modules (two sessions of one hour each) with computer-based coding, and one of the comments that was made in support of computer-based coding bothered me enough that I thought that I should write a post about why it bothered me, and maybe start a discussion about it. That comment? "Whiteboard coding is unnatural".

The particular phrasing there struck me, but it's part of a larger argument against whiteboard coding that I've seen cropping up from time to time, which says that what the coding that we (as software engineers) do in our day-to-day jobs doesn't at all resemble what happens on a whiteboard, and we should change the coding portions of the interview to better reflect the style of coding that we do. It's a seductive argument since, in the end, isn't the purpose of an interview to determine if you can perform your job at the required level, and isn't the best way to test that to simulate the work that you would be doing and see if you meet (and hopefully exceed) some bar?

I'll let that bounce around for a bit and go on a tangent about what's being discussed here, since I've also seen a lot of different ideas about what a computer-based coding interview 'should' look like. This is specifically around replacing two hours of writing code on a whiteboard with (approximately) two hours of writing code on a computer. This isn't about take-home coding exercises (those tend not to go over well with people pursuing multiple opportunities and more-experienced people, both types of people that LinkedIn is looking for), or 'hackday' interviews (A full-day interview which is basically 'build a cool feature, then explain it to us'. It goes over well with product-oriented people and not-so-well with people who aren't). I'll also note that LinkedIn has tried computer-based coding interviews[1], and we abandoned them partially because we were having trouble with too few people passing them and partially because of the effort to maintain the coding environment, especially around multiple languages. So, I've had at least passing experience with it in actual interview situations and I'm not just arguing from ignorance.

Alright, back to the discussion: Is whiteboard coding unnatural, and should we change it? To the first part, I say "Yes, it is.". Whiteboard coding doesn't resemble my day-to-day coding in any real sense. I don't think that there is any way to defend a position that it does: You're writing without any of the tools or techniques that we have developed to improve our abilities, and as much as we might try not to, our coding styles are shaped by and around the tools that we use. People are used to using autocomplete, library references, syntax checking, unit tests[2], and a host of other tools when they code. None of those can be used in a whiteboard coding interview, and I've heard from many people that a major part of interview preparation these days (in addition to picking up an algorithms book at your local college bookstore) is learning to write code on a whiteboard.

But, I would claim, the entire interview process is unnatural. I will never in the course of my daily work (I hope) be writing code, under time pressure, while being watched by someone who not only knows better ways to approach the problem than I do, but is also going to shortly decide if I will continue being employed. If I were asked, in the course of my daily work, to write a function that computes integer powers I would need a very good explanation of why I wasn't using a built-in power function rather than trying to write my own. If someone asked me to design the architecture for a website to play Hangman, my first response (after clarifying what they actually meant) would probably be to spend a few days bouncing ideas off other people rather than trying to write a good architecture up from scratch. Even among the biggest fans of pair programming, speaking your every thought out loud as you are programming isn't something that you would do - it would interrupt your own thoughts too much.

Interviews are, by their nature, an attempt to determine, in around 8 hours, if someone who has been programming for years is now /and will continue to be for the next few years/ a good fit for whatever it is you want them to do, while they do the same for you. A natural interview would be something like hiring them provisionally for a few months, and offering them full-time employment based on their output during that time. That's why internships are so great. But most people, especially the people who you really want to work with you, wouldn't go for that sort of interview. Whiteboard coding is not a way to simulate the coding that you would be doing if you were hired. It's not about checking off the 'can actually write code' box on some list of qualifications that candidates need to pass your bar. It's a tool to let you evaluate a candidate's thought processes while coding and how they approach coding problems, and at that it's much better than sitting people down in front of a computer and asking them to code. Since that's what we're looking for in all of our coding interviews, it seems only natural to use the better tool there.

That isn't to say that there aren't any questions that benefit from access to compilers and IDEs. In particular, questions around finding and fixing bugs, or expanding an existing codebase ("Here is an implementation of a tree-backed Set. Make it thread-safe and fast"). When working on existing code, or in places where a test execution is important and non-trivial, the IDE and compiler are invaluable and part of our normal workflow. But while that's an important skill, I meet many more candidates who can't figure out what code they should be writing (even if the code they /do/ write is compilable) than I meet who can put it down in whiteboard pseudocode but can't translate that into something compilable[3]. As such, I see those types of questions as supplementary to the core "can you figure out what code you should be writing" questions rather than as a crucial evaluation are in and of themselves.

Whiteboard coding is language and syntax-agnostic[4], and I trust that if you can think well and write good code in one language, you can learn ours in a few weeks at most. In an IDE it feels strange to assume the existence of some helper function that isn't really that important (and you get a red squiggly line for it), whereas on a whiteboard saying "And we assume a function that determines if a character is a digit or not" seems fine, and in the context of an interview it shouldn't matter if you can write that code or not (if you can't, you'll be having other problems). In some cases, it's even enough to sketch out the high-level data flow and interactions and only write code for the interesting parts ("Alright. How would you pre-process the set to allow the graph traversal?"). While in some cases you would actually want the candidate to write a breadth-first search algorithm to do the traversal, in others it is enough that the candidate says "I'll need a queue and a visited set to do the BFS" and you can wave them on. Whiteboards give you the freedom to easily do that, IDEs less so. There also aren't any interface problems with a whiteboard, whereas with an IDE anything from not having your preferred IDE available (IDEA? Eclipse? emacs? vi?) to not having the right keymappings (Windows vs. MacOS vs. Linux) can hamper your progress.

It also feels much less unnatural to explain what you are doing, write it, and then step back to consider the next step when you are at the whiteboard, which gives the interviewer the invaluable insight into how you are thinking about the problem and why. That has as much to do with the context that we usually deal with whiteboards in (discussing things with our peers or trying to lay things out for ourselves) versus the context that we deal with IDEs in (solitary, or at least fully absorbed, production of code). But that insight is, ultimately, what matters: The core assumption is that if you can think well and clearly, and can translate those thoughts into code decently well, you will be able to do that for a wide variety and scope of problems. That scope includes ones that neither you nor anyone else has seen before. It's not about simulating what you would be doing, because we don't have time for that in an interview[5]. It's about using interview questions as tools to try to predict how you will do in situations that we can't test you for. Interviewing is always an information maximization subject to time constraints problem, and given all of the above whiteboarding as an interview tool gives much better information density than computer-based coding. Complaining about whiteboard coding not simulating daily work misses the point that it wasn't ever supposed to be a simulation, and treating it as if it were won't give good results. Whiteboard coding is an evaluation tool, and using it correctly will yield more information, faster, than trying to simulate daily work. Why then should we abandon it because it isn't a simulation?

[1]
23 people did an interview where we took questions calibrated to be completed in 60 minutes, gave them 90 minutes with a laptop, IDE, and sample inputs as well as 15 minutes at the beginning to discuss their approach, and did a 15-minute 'code review' at the end.

[2]
All of which, incidentally, we provided in our test interviews

[3]
This was, I think, born out by our computer-based interviews, where only a few of the candidates didn't have something that compiled at the end, but many of them weren't going about the problem well.

[4]
And if you are one of the people that insists on having compilable code written on whiteboards during interviews you are, with all due respect, doing it wrong.

[5]
Indeed, in almost any project that isn't 'build this from scratch' has the first few days of work as 'poke around the system and figure out how it works right now'. We can't simulate poking around something as complex as an established codebase in the space of an interview.