
The Rise and Looming Fall of the Engineering Whiteboard Interview - rvivek
http://www.forbes.com/sites/vivekravisankar/2015/05/04/the-rise-and-looming-fall-of-the-engineering-whiteboard-interview/
======
phuff
"Back in the ‘60s and ‘70s, when microcomputers like the Apple II were all the
rage, computer time was expensive, pressure-packed and cumbersome."

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?

~~~
31reasons
Also it should be mentioned that the author is a co-founder of HackerRank.com
, which is trying to be the testing platform for new interview candidates.

From the article, I didn't get any information on why or what or if there is a
"Looming Fall" of the whiteboard for testing engineering candidates.

~~~
toomuchtodo
> I didn't get any information on why or what or if there is a "Looming Fall"
> of the whiteboard for testing engineering candidates.

Because its a product placement article (selling HackerRank).

~~~
josephkern
"Native Advertisement"

------
joesmo
The worst part of the whiteboard in my opinion is not that it's a poor tool
for the job, which it is, but that it adds both unnecessary social pressure
and the need to constantly explain what's going on (presumably because the
interviewers are bored so for their amusement) while simultaneously trying to
think, write, and edit out a solution. The fact that you can't run or even
edit code very efficiently on a whiteboard (or paper) alone makes it a
terrible tool to judge anything about a candidate, but combined, the two make
the whole exercise pointless and quite frustrating for the interviewee.

------
cpprototypes
The whiteboard is actually not the main problem, it's the other things that
often come with whiteboard coding. The main problem is that these type of
interviews expect you to master the skill of talking, thinking, and coding
simultaneously. The reason given is to "see how you think" but there's no
reason this must be in real-time, questions could be asked after allowing the
candidate some quiet privacy to work on a solution. To illustrate the main
issue, replace the whiteboard with a computer connected to a projector
instead. The main issue is still there. A group of engineers silently sitting
there, judging, watching every move, and expecting you to keep talking while
thinking and coding. This is NOT how programmers work. Most programmers sit
down, think about a problem silently, then try out a few quick code snippets
to explore the problem, then create a design, and then begin coding.

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.

~~~
innocentoldguy
I think conducting any kind of test during an interview is a waste of time. If
someone comes in with a resume that clearly demonstrates years of relevant
experience, a Github account with examples of things they've worked on, and if
they can talk intelligently about the problems I'm trying to solve, that's all
I really need to know about their skills.

I couldn't care less how someone thinks. What I want to know is do they have
experience writing code and more importantly, are they the sort of person I
would enjoy working with. Both of these questions can be answered in more
effective ways than a test or whiteboard question.

------
yodsanklai
I don't see why the whiteboard is so unpopular here. Isn't it a good way to
see how people are able to discuss solutions and share ideas with their
colleagues?

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.

~~~
innocentoldguy
There are myriad problems with whiteboard questions:

1\. The questions are always esoteric and have absolutely nothing to do with
the company's business (unless, of course, they are in the business of
generating Fibonacci numbers or CSS flags).

2\. The situation itself is completely unrealistic and in no way demonstrates
"how a person thinks" in a programming situation; which is weird since that
is, after all, the universal rationalization for asking whiteboard questions
in the first place.

3\. Most, if not all, interviewers have no idea what to do with the
information they observe in a whiteboard situation, so regardless of the
result, it just becomes a confirmation of whatever opinion they formed within
the first 30 seconds of the interview.

In my experience, whiteboard questions demonstrate a lack of interviewing
skills and are a waste of time for everyone involved. I refuse to interview
people that way, and I'll walk out of an interview if someone asks me to solve
something on a whiteboard. If you want to see my code, go to my Github
account. If you want to see how I solve real-world problems, I use past
experience, Vim, a debugger, a terminal, my gists, Dash, and Google. There.
Did we really have to waste an hour of everyone's lives to get to that answer?
Absolutely not!

------
rqebmm
There's no bad interview question, but there are certainly bad interview
_processes_. We use a whiteboard session as the last step in the technical
interview, and we're really not looking for someone to write functioning code,
we're looking for the candidate's thought process as they lay out a design for
a simple OO 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.

~~~
darby2000
There are a lot of bad interview questions. Like "Why do you want to work
here?" ... I dunno, cause I thought you would pay me.

~~~
buckbova
That's a fair question and gives insight into the person's
objectives/aspirations.

"I need a paycheck" is a great answer for some positions, but a person in
demand would have choices, so it's valid to ask "why us?".

~~~
m3talridl3y
Interesting, so I should pretend to be very in-demand to game your interview
process. Good to know.

~~~
rifung
Why the need to be snarky to someone who was just trying to give insight as to
why this question was asked?

~~~
harry8
Why do you think that was a snarky response devoid of insight? I didn't.

~~~
rifung
In what way is announcing that he was going to try and game someone else's
interview process insightful?

Not only that but it's not even clear the person he/she is responding to
actually is part of an interview process as opposed to just explaining the
reasoning behind the interview question.

Personally I found it needlessly rude and even rather bitter but if you feel
like it provided some value then I'm glad it was useful.

~~~
innocentoldguy
It is insightful because gaming the system is exactly what people do. When
someone asks me, "What is your greatest weakness," I typically say something
stupid like, "I guess my greatest weakness is that I don't spend enough time
with my family because I tend to work all the time," instead of the reality,
which is, "I fantasize about having meaningless sex with every woman I meet.
Even the homely ones."

When someone asks, "Why do you want to work here?" I might say, "Because I
find the way your company puts input fields on a web page to be fascinating,
and I want to be a part of it." The reality, however, is I want a damn
paycheck and I couldn't care less what the company does.

The point here is that nobody answers these questions honestly. Nobody. So
what on Earth is the point of asking them? There isn't one. These questions
just fill up space during the allotted hour of interview time, and are used by
the interviewer to justify the opinion they formed within the first few
seconds of the interview.

~~~
rifung
Fair enough. I thought it was obvious that people try to game the system, but
I can see how if others didn't think the same way it would be insightful.

On the other hand, what's the point of asking anything during an interview if
people can lie then? I imagine these questions are still being asked because
it's not all that easy to lie and still sound authentic. I also agree with you
though. I think this whole idea of trying to find people to work at a company
because this is their dream company is just a silly fantasy for 99.9% of
companies. Unless you're Google, chances are slim that working is nothing more
than a job.

This whole craze over wanting to love your work and being "passionate" and
"excited" is getting out of hand. I feel like I see the word "excited" thrown
around everywhere now.

~~~
innocentoldguy
I agree. It is getting out of hand.

I try to be more pragmatic in my interview process. I don't expect candidates
to be passionate because the company isn't their dream. I expect the owner to
be passionate, but the rest of us are just here to pay the bills. Therefore, I
don't bother looking for passion. What I do want is somebody who has coding
experience and someone I'd enjoy working with. I focus all my questions around
those two goals, with a greater emphasis on the second.

------
api
I've been programming since I was four. Was doing 6502 machine code at eight
or nine. I know over ten languages pretty fluently, and have done everything
from high level web and desktop stuff to bare metal kernel hacking.

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.

------
drawkbox
The whiteboard interview attempts to be used as a way to figure out a
developers thought flow, however it is a flawed system....

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.

~~~
innocentoldguy
I was asked to write code to solve this problem during an interview once:

"You are driving at a constant speed. After a while, you pass a mile marker
with a two-digit number on it. One hour later, you pass another mile marker
with the same two numbers on it, but in reverse order. In another hour, you
pass a third mile marker with the same two digits separated by a zero. How
many miles per hour are you traveling and what numbers were on each of the
mile markers?"

When I started working at the company, what was the first thing they had me
do? Convert all the tabs in their Ruby source files into spaces.

That right there is the problem with whiteboard questions.

------
m3talridl3y
Just like many programmers fail at FizzBuzz, many interviewers have no
business conducting interviews. Also remember that these practices will
continue until someone educates them. So, the next time you're given 45
minutes to code up a radix sort in a whiteboard, instead start a discussion
about interview techniques. The socratic method goes a long way to making
people realize just how much they are cargo culting.

------
mathrawka
When I hire someone this is my script:

#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.

------
aarestad
Google still seems to love their whiteboard interviews, to the point where you
have to write syntactically correct Java, under pressure, for a rather
difficult problem in only 45 minutes. It's stressful as hell, and has almost
certainly driven off lots of good programmers. My company does sit-down
interviews with a computer (usually a Mac) and the interviewer's choice of
IDE. We get much better results that way - coding under pressure is still
hard, but at least the IDE can save you from making easy mistakes under
pressure, and you get immediate feedback about how you're doing, rather than
just going on the ambivalent nodding of an interviewer.

~~~
rifung
Microsoft also still does whiteboard interviews.

Also, one of the issues of providing an interview candidate with a computer is
that some people are very particular with their environment.

For example, even if you let them use an IDE they are familiar with, maybe
they really don't like using Macs. Or worse, they don't even use a qwerty
keyboard.

In my company nobody uses an IDE, I use vim and the other developers use emacs
or sublime. I think we all have our own little plugins/settings that we use as
well.

Of course you could solve all of this by letting employees bring their own
computer, although not everyone has a laptop either. To be completely honest,
I really like the whiteboard but I definitely can see why others don't like it
and get the impression I'm in the minority.

~~~
mmcconnell1618
I spent a day interviewing last week one of those companies. 3 whiteboard
interviews during the process. I'd say it's far from dead.

I was asked to write syntactically correct code in a specific language on a
whiteboard with a time limit. That's very far from how I work on a daily
basis. I could understand writing pseudo-code or explaining architecture but
what possible data can you gather from how well I draw curly braces on a dry
erase board?

------
alexwebb2
I just switched to coderpad.io, and so far I really like it - it takes the
place of a phone interview. I'm looking for JS engineers, so I've set up a
series of stub functions representing problems - with corresponding tests for
each of them. If they can make all of the tests pass within half an hour, they
advance. They can ask all the questions they want, search the internet,
whatever gets the job done.

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.

~~~
innocentoldguy
Here's the thing though. I find these sorts of tasks a waste of my time. I
know from personal experience that I can ditch your interview and go get hired
by numerous other companies who don't waste my time with drawn out interview
processes. Therefore, you're not really testing my skills as much as you are
my patience, and I simply don't want to be bothered. I know a lot of other
engineers who feel the same way.

Now, if you want to pay me $80 an hour to code a bunch of fluff for you,
great! Otherwise, I'm more inclined to look for shorter paths to entry
elsewhere.

------
erobbins
and lo, there was much rejoicing throughout the land.

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.

~~~
BSousa
See, this is where 'different strokes' thing comes in handy. I HATE HATE HATE
pair programming. If you tell me I have to do 1 hour of pair programming on a
job interview, I won't go. Not because I'll get nervous or anything, I just
don't like a few things about it, a couple:

a) I hate having people in my personal space I don't know well. It may seem
I'm being an asshole, but I'm very very very very sensitive to smells to the
point that I can't concentrate. Your cologne or just body smell will probably
be my number one focus throughout that hour.

b) while I don't have OCD/am a germaphobe, again I HATE HATE HATE using a
keyboard that isn't new or mine. The stickiness of the keys, the dirt around
them... makes me go crazy.

I always carry my laptop to interviews with me nowadays to at least avoid B.

So, for me, a whiteboard is great (for some reason, I don't care much about a
dirty board/pens) and I do amazingly well on them. I also do very well in
public speaking situations so maybe I'm just comfortable at that kind of
interaction/distance.

I think the best is to truly ask the person what they prefer. If they want a
laptop, great, if a whiteboard, cool as well, I've done both both as an
interviewer and interviewee, and noticed that as well, some people prefer a
whiteboard, others a laptop. Give them what they are more comfortable with.

~~~
drawkbox
Pair programming physically side by side is not great. Pair programming or
integrating/coding together remote over Skype/Gotomeeting/etc screen sharing
is great when needed.

It is like having another programmer in your head and you can't see each other
type so there are less jibs/jabs. Plus both people can eat, drink, do things
rather than just stand around one workstation like people did with TV in the
50s and one person can't see the screen.

I can't remember the last time I pair programmed in person over remote even in
the same office/building. Occasionally you need to be in the same room or desk
to draw something up but mostly it is more efficient remotely especially
during an integration.

Pair programming remotely is like "hey you got a bug on line 441", pair
programming side by side physically is like "dude you got a bug down there,
btw just just use this hotkey" or doesn't even see it because you can't see
the screen.

~~~
BSousa
I agree. I work remotely and do this a lot with team members, but when people
suggest pair programming, they are (usually) referring to 2 seats on 1
keyboard kind of thing, which I hate and would probably quit if I had to do it
on a day to day basis.

------
LordHumungous
God, programmers are the biggest whiners in the world when it comes to
interviewing. Do you know the shit doctors and lawyers have to go through to
get hired? If you did, you'd thank Jesus that all you have to do is solve
problems on a whiteboard. If you can't do it, then here's a simple and
effective solution for you: practice!

~~~
innocentoldguy
In the case of doctors, yes, I do. They demonstrate that they have a medical
degree, have completed their residency, have passed their boards, and then
provide proof of prior work experience. What they don't have to do is perform
some esoteric and completely irrelevant surgical procedure on a gourd.

The reason the practical among us are complaining about whiteboard questions
is:

1\. They are arcane and esoteric and do not reflect the day-to-day activities
of the company.

2\. Programming is an iterative process complete with tools, visual feedback,
and documentation. A whiteboard question takes away all these things and puts
the engineer in an unrealistic situation. Using you doctor example, it would
be like asking a doctor to prove their medical skills by performing a microtia
repair on a banana using a bra and a bouncy house. Fun, of course, but
completely irrelevant.

3\. They are the sign of an unskilled interviewer.

Personally, I have no interest in practicing to master the impractical,
irrelevant, and incompetent whiteboard question skill when I can simply go
interview with a company who knows how to conduct an effective interview.
Maybe the prestige of working at Google or Microsoft is worth it to people to
slog their way through those kinds of interviews. Personally, I went through
Microsoft's interview process and ended up working there for over a year. I've
had better jobs and I still think their interview process is retarded. I
certainly wouldn't put myself through it again.

~~~
LordHumungous
> They demonstrate that they have a medical degree, have completed their
> residency, have passed their boards, and then provide proof of prior work
> experience.

Oh, you mean that's _all_ they have to do? If you think being judged by a
whiteboard problem is arbitrary, imagine being judged by your score on a fill
in the bubble boards exam. And even after getting their degree and passing the
boards, doctors still have to go through an interview that would make the
average programmer cry. I worked directly with doctors for several years, and
almost tried to become one myself. The shit they have to deal with is on a
whole other order of magnitude from anything programmers go through.

~~~
innocentoldguy
I have worked with surgeons and anesthesiologists for the last 12 years, so I
know what they have to do as well.

One important thing to keep in mind is that a surgeon or anesthesiologist is
taking their patients' health, and even their lives, into their hands when
they operate. I've written code for 25 years and nobody's life has ever been
at stake.

Furthermore, when something is stupid and a waste of time, it should be
discussed, dealt with, and eliminated; regardless of how many other stupid
things exist in life.

------
source99
I generally agree with the article in regards to social pressure/anxiety being
very high for a whiteboard style interview.

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.

------
muktabh
"Whiteboard problems were never meant to be fast, scalable or simulate real-
world problems to ensure high-quality hires." No "problems" can simulate a
real world situation, real world development is not a set of questions to
solve. Not even the popular problems where the person is asked to do stuff
like write a zigzag binary tree traversal or put ant on a chess board.

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.

------
danielvinson
The fact that there were 4 pages for this little text (with multiple
unnecessary charts) annoyed me enough to forget what my actual complaint was.

~~~
sarciszewski
I came here to say pretty much the same thing.

------
rasz_pl
I was asked to do whiteboard interview once. I simply laughed and thanked for
wasting my time. This was a company that knew me from previous jobs and they
still insisted on this pointless exercise (1). From that point on I start by
asking first, I dont do whiteboards, I dont do quizzes, I dont do
personality/aptitude evaluations or out of the box tests. There is no point in
asking me what some silly obscure acronym means when google is 2 seconds away,
or testing if Im a team player if Im being hired to sit in the basement and
staple patch cords together.

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 :/

------
steven777400
We did "whiteboard" coding up until just a couple years ago but I've been
pushing all our dev teams to switch to actual real "on computer" coding for
interviews. At first there was some concern, but really, it works out a lot
better.

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.

~~~
ctide
You know what isn't setup the way my normal editor is?

A fucking whiteboard.

------
schintan
The article discusses Software Engineering interviews, not all engineering
interviews and the title should reflect that.

------
kelukelugames
[http://www.forbes.com/sites/vivekravisankar/2015/05/04/the-r...](http://www.forbes.com/sites/vivekravisankar/2015/05/04/the-
rise-and-looming-fall-of-the-engineering-whiteboard-interview/print/)

One pager.

------
baddox
> For the past few decades, most engineers require candidates to code on a
> whiteboard.

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_.

------
jboy55
Is the whiteboard interview perfect? No, there is no perfect method.

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.

~~~
cnp
I've choked so bad on whiteboarding interviews that I've felt ashamed for
weeks; yes, I am one of those people. But then when I broke the anxiety after
practice, they became easy. The key is understanding that it's the process
over the solution.

However, I'm quite proud of the fact that where I currently work we _never_
ask someone to code on a whiteboard. Rather, we ask them to complete a take
home test and then, when they're ready, invite them in to discuss their
choices and augment it functionally. This practice is, in my opinion,
holistically far more effective at gauging a candidate's competence and
ability.

~~~
twistedpair
Sadly I was able to find various great solutions to my take home programming
assignments after the fact. I submitted my own original solutions, but I'm
sure there are others that didn't bother/know how and submitted the other
solutions they found online. I'd like to think the interviewer had an
exhaustive list of Google search results for the problem, but I sadly doubt
it.

~~~
cnp
What I mean about take home test is "build an app that does x y and z, write
tests, talk about your choices" \-- something that you can't quite google.
Take home tests for questions like "explain how to use fn.apply()" wouldn't
work :)

------
exratione
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.

