Whiteboard Exercises are a Terrible Way t...

面试的时候，你遇到过这样的情形吗？给你一张白纸或者试卷，要求你直接手写代码？注意，不是伪代码哦。看到国外一个家伙写了篇文章，来阐述自己对这种所谓检验面试人员编码能力的方式的想法，觉得很不错，果断转过来。（惭愧，话说我还一直认为这样才能真正检验自己对一门语言掌握的能力，惭愧！再就是，我英语很烂，看这篇文章我是连蒙带猜加查单词，相信其他筒子的英语水准一定是比我高很多，看这文毫无压力！）

文章出处：Whiteboard Exercises are a Terrible Way to Investigate Coding Ability

I don't participate in interviews as the interviewee all that often, and when I do it's rare for me to be asked to solve a trivial problem on a whiteboard. Ex Ratione exists in its present form to smooth and speed the establishment of solid developer-client and developer-employer relationships, and one small portion of that involves bypassing the whole time-consuming "show us you can code something, right here, right now" dog and pony show. You'll find code and discussions of code here and in my Github account, after all.

Thus the whiteboard coding exercise has materialized for me perhaps twice in the past decade, and both times have been a reminder of just how terrible it is as an interview strategy.

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.