The Rise and Looming Fall of the Engineering Whiteboard Interview

Does no one fact check anything anymore? If you're going to base part of your argument around technology that was around before you were born maybe do a little more research? And also... get off my lawn? Am I really that old?

It would be a huge improvement if companies just gave the candidate a problem, left the room, and came back an hour later. Then they can discuss the solution, ask questions about the code, etc. The key thing is, let them do some quiet alone thinking instead of having to worry about someone watching every move and expecting constant talking.

The way I see it, one could start to find a solution on the whiteboard, possibly with some help from the interviewer. And next stage is writing the actual code, which can be done easily on the whiteboard if it's a short program.

For the type of programming I'm involved in hiring (iOS/Android) it's silly to expect someone not to lean on frameworks/IDEs. It's also unrealistic to expect that every single candidate has a laptop fully set up with their preferred environment. That's what take-home questions are for.

I can't code on a white board to save my life. It all just falls out of my head.

I've heard others say the same thing, so I suspect I'm not at all unique here.

Many programmers are introverted and not always the best at speaking in front of people they just met, most people aren't.

The skill the whiteboard is checking is not the skill that will be used on the job, it is overly focused on an extroverted personality and how well this developer can present to new people. An introverted developer might mess up in an interview but be making the best designs, products and presentations to the team later when the team is known.

The true test is in the trenches and no test in an interview by a select few people in the company can ever tell product delivery and developer skill, the interview steps are just some litmus tests. Companies want the best and brightest but many are getting cut off at the pass from a whiteboard. Is the interview really where we determine who is the best, not the work? What costs more, losing a good developer to an interview process or letting someone in you determine isn't a good fit 1-2 months in on a small project.

#1 I introduce myself and what the project(s) entail and how things get done.

#2 I ask them some questions about their experiences, and ask them to tell me a story about some past memorable experience.

#3 I ask them to do a simple coding exercise (5 - 10 mins tops). If they bomb it, I don't care, what I want to see is how they _react_ to feedback. Some people will get belligerent during the interview, and that is definitely a red flag that I will not enjoy working with them.

#4 I let them ask me any questions they have and then wrap things up.

I think hiring engineers with a specific skill is great for a contracting position. But if you want to hire someone in a full time position, some learning on the engineer's part is to be expected.

For the in-person interview, I sit them in front of a laptop and give them one hour to develop a ToDo app from scratch. Bonus points for things like test cases, mobile deployment, multi-user support, you get the idea.

Whiteboard coding is a terrible practice that should have died 15 years ago. 1 hour of pair programming on a real computer (even locked down with no network access) should tell you all you need to know about a person's skills.

However I disagree with its sentiment that coding resources are free and have no cost. I think this attitude leads to poor quality code. My reasoning is that if you don't have to spend any effort to write code than you will write the laziest code possible. This code might work but it will only work because it evolved from the wrong solution to a barely working solution. If compute time was more of a scare resource developers would spend more time writing correct code instead of iterating until something works.

I don't mean that all developers code poorly because of the decrease in the time of the iteration loop but I feel that it does lead to poor code in the general case.

Also I still have to understand why interviewing has to be a scalable process. Are we interviewing 1000s of candidates at a time at some company ? From all I can think that is totally not the right place for a company to be. Granted there are millions of upcoming jobs, they are distributed across too many companies/teams , so the number of interviewees per head would be more or less constant.

"Programmers in this era were just used to the idea of writing code on paper. " So no one in current age group is comfortable planning on a whiteboard ? Does the author think that things are not planned on a whiteboard in real life ? I am 27 years old (maybe too old according to the article but still I was never a part of the punched card generation ) but how does that count as a reason not to ask someone younger to explain his/her approach or how they incorporate feedback on a whiteboard ? Whiteboard interviews are not meant to check if a interviewee can memorize the language constructs properly as being portrayed by the article, if such is the case, the candidate better walk away.

Google can pull this BS because they pay good money and are at the top of their game. But 100 employees boring 9-5? lol no. Lets face it, I dont need you, you need me. You came to me first.

1/ I returned twice as a contractor to fix shit build by new employee screened with white board :). This wasnt even a big company with strict corporate ruleset, they were just clueless :/

The biggest still valid objection is "it won't be setup the way they are used to and so it will take too long for them to be productive even for a toy problem". Maybe. It seems like even they are used to a different color scheme or IDE plugins or whatever they should be able to figure out a default setup enough to write a toy algorithm. Maybe not.

One pager.

Citation needed for the first sentence. I have always heard of whiteboard coding interviews, but I have never heard that they are common and certainly not the majority.

Disclaimer, I give lots of white board interviews. What am I looking for?

Syntax? Nope, I let the candidate use any language they want, they can even make it up as they go, as long as its consistent and doesn't contain magic. Most of my questions are simple and operate on arrays.

A good talker? Not really, although someone who freezes up and can't talk might be an issue discussing their ideas in a group, but its not disqualification. The number of people who have been actively anxious to the point they can't code anything on the whiteboard? Never encountered it, I've given maybe 500 white board questions.

My question revolves around iterating through an array, keeping track of a couple of pointers, and doing some simple swaps, its a sorting problem. I'm looking for people who can think 'step by step', people who can look at a very simple program, and keep track of how its executing.

You might say, you have an IDE to do that! IMHO, Any decent programmer can look at 8 lines of code and step through that . Most of the time, when I'm debugging something in prod, I only have a stack trace and the source code. I have to figure out how the trace could have been thrown, and I have to step through a bunch of code to figure that out.

Finally, Whiteboard coding is a skill, just like how to debug or how to import a project into an IDE; its a necessary skill to get a job. Plus, when I look around my room, I can spot 3-4 whiteboards, all of them have code and diagrams written on them. None of those came from an interview, those are all the result of one engineer communicating to others about their ideas.

edit: Last thing, the alternatives, side by side keyboard coding, a take home project. All of these have cons, keyboard anxiety is just a prevalent as whiteboard, just a different medium. Take home projects are nice, if you expect a candidate to spend a weekend coding for your interview. Just as people have walked out because of a whiteboard interview (something I've never encountered), I've actually dropped pursuing a company when they gave me a fairly complex take home project when I was at the offer stage at a different one. Fuck spending a day working on some throw away work and not get the job.

It is Slow, Slow, Slow

I am actually greatly in favor of short programming exercises as a framing strategy for interviews. A sort of ersatz pair programming is the way I like to interview candidates: dive straight in with two seats at a machine and get to know the fellow over the course of either a bug hunt on the system he is being hired to work with, or if that's impossible for legal or other reasons then some small, fun coding exercise. Such as, say, "implement the world's worst way to represent and then reverse a linked list," or anything that starts with "you have an infinite tongue floating on a lake of a coffee and a piercing tool..."

Ditching the keyboard in favor of a whiteboard dramatically increases the time taken to evaluate any one shard of the programming experience, however. What can be accomplished neatly with a simple text editor in ten minutes can take a painful hour or more with a pen. Whiteboarding is simply not suited for the exploratory way in which most people code. All that wasted time would be put to far better use in talking, asking questions, and more deeply exploring the interviewee's approach to coding as a profession - touching on the many, many vital aspects of being a developer that cannot be tested in an hour with a text editor and a compiler.

Whiteboarding Primarily Tests for the Ability to Whiteboard

Most folk don't spend their lives working on how to most efficiently and effectively use a whiteboard. There are good reasons for this: we have computers now, with editing and presentation software that is ten thousand times more useful and functional than the combination of pen and whiteboard. Why would anyone choose to practice and optimize a skill that is never going to be used in the ordinary course of their professional life?

Nonetheless, there exist a small number of people who can whip up really great presentations on a whiteboard from scratch, even over the course of a discussion that swings around all over the map, and has no predetermined outcome. These talented folk will make great use of space, have little need to erase and redo, and will generally look good while doing it. But guess what? That skill, while very occasionally useful, has absolutely nothing to do with code or programming.

Most people, given a whiteboard and a free-ranging discussion or problem to solve, will produce an ugly-looking hash of notes and require frequent large-scale reordering of the content on the board to make sense of it all. If you weren't there, it might as well be Hebrew or hieroglyphics. If you were there, it still requires an additional investment of effort to follow what is happening - effort that might otherwise be going to more productive interview strategies.

Erasure and Exploration are Punished Aggressively

People are very individualistic when it comes to that aspect of development that involves the choice, design, and implementation of algorithms - the sort of thing that might take a few minutes to an hour and will typically be just a small part of a larger task. There are as many different approaches as there are types of personality. For my part, actually writing code is exactly equivalent to thinking about the problem: I plunge in and start writing, as that is the process by which I get a handle on what the eventual solution has to involve and how it will be organized. I'd guess that I probably write at least two to three times as many lines of code as eventually exist in any given small solution, and it is the rare module that isn't aggressively refactored or otherwise turned inside-out at some point within the first thirty minutes to an hour of its existence.

In a text editor, this is a very rapid process. It goes about as fast as I can type. On a whiteboard? Not so great. Forcing code away from an editor and into a whiteboard is, I think, a great way to sabotage anyone who approaches programming in a rapid, iterative, and exploratory fashion. The whiteboard favors instead that mythical beast, the programmer who assembles the whole solution in his head, perfectly visualized, and then just writes it down.

But where's the fun in that? If that was the way I coded, I probably wouldn't be doing it for a living, or writing software in my own time. Rapid exploration and thinking out loud in code is a key part of the process of development at the small scale - of exploring any particular modestly-sized problem space. Of course this is all very different from the strategies apply to a larger scope of work, or software architecture, or the planning of complex integrations ... but then you aren't going to manage to see the nuts and bolts of any of that via a short coding exercise.

Small Problems are a Tiny Subset of Programming as a Profession

The only thing you have time for in any coding exercise, but especially when whiteboarding, are tiny challenges - minuscule slivers of the vast programming experience. Just playing the odds, the ability to generate an algorithm for a small isolated problem is likely neither the most important component of the job, nor in any way related to the actual strengths or weakness of the interviewee as a programmer. What about planning, big picture thinking, documentation, writing skills, foresight, innovation? And so on, for as long as you care to make the list.

Further, the artificial whiteboard environment is far removed from anything approaching a real development environment. Every developer works within a halo of resources, local and online: the IDE, Google, Stack Overflow, and so forth. They are surrounded by an ethereal library and the means to use it - a primitive exobrain if you like. A large part of being a good programmer is being aware of and skilled in the effective use of this exobrain. Pen and paper coding exercises in this context are something akin to testing medical students by shutting them in a room with leeches, potions, and a patient, and expecting to divine something of their ability to perform in a modern hospital setting from the results.

Since whiteboarding is excruciatingly slow, by using it you've chosen to put the majority of your interview time into a poor-quality examination of one tiny facet of the programming experience, rather than freeing up time for other and better approaches.

"But Several People Need to See What's Going On"

Ah, the group interview. So move the chairs closer to that gargantuan developer-sized monitor you have. Or request a bigger monitor. Or use a projector. I believe we've moved somewhat past the whiteboard as the only available technology for presenting content to multiple people in the same room at the same time.