
Writing code on whiteboards is hard - lx
http://ericlippert.com/2015/06/01/writing-code-on-whiteboards-is-hard/
======
mikeash
So why are you having candidates use a whiteboard?

I don't understand why this approach is so popular for interviewing. If you
want to give the candidate a practical programming test (and why not? seems
wise to me) why not have him actually write some code on an actual computer,
in a normal programming environment?

Personally, I have no problem with whiteboard programming. I think it's fun
and it doesn't stress me. But I don't understand why we _do_ it instead of
letting people use an actual freakin' keyboard.

Imagine if you were interviewing a car mechanic and you said, OK, on this
whiteboard here, draw out how you would change an oil filter. You'd have to be
completely mad! If you want to test his ability to change an oil filter (and
why not? that's something they should be able to do) then get a car and say,
show me.

I can't see _any_ advantage to the whiteboard, so why do we do it? The only
thing I can see is that it would have saved on capital costs back in the
ancient days of yore when computer hardware was expensive and quantities were
limited and getting every candidate in front of a computer wasn't practical.
Thankfully that's not remotely true now.

~~~
robotkilla
He gives a bunch of reasons for what he's actually looking for (the way you
problem solve etc) which is the first time I've heard an interviewer give a
reason for the whiteboard test.

Ultimately the author is after the candidates thinking process and he
misguidedly (in my opinion) thinks a whiteboard test will help him get that
information. But instead, it will help him find people who are good at
whiteboard coding under pressure. People who have practiced for that
particular activity which they will not be getting paid to perform on a daily
basis... just like asking brain teasers help you find people to hire that are
really good at solving brain teasers (but may suck at their actual day to day
job).

Edit I'm going to use this opportunity to point out that I have been
freelancing as a python / node.js / php / front-end (js, html, less etc) for
about 4 years full time, 12 years total. I worked for a number of companies
(small and large) for around 7 years. I get almost all of my current work
through word of mouth and reputation. The interview process is pretty much me
telling them what I can do, telling them what I have done, who I know and
that's it I'm hired within the same phone call and I make a hell of a lot more
money solo than I did when I worked fulltime (I'm getting ready to scale back
to 20 hours per week to work on a project of my own).

Yet, when I attempt a whiteboard test, a brainteaser or just about any other
interview question for a full time position, unless I'm able to get past my
crushing depression, social anxiety, interview anxiety etc. I will fail
spectacularly. The entire standard interview process (and tech job for that
matter) is total bullshit.

~~~
mikeash
He gives reasons for a coding test, but he gives no reasons for preferring a
whiteboard over a computer. The idea of using a computer barely gets mentioned
and is never really compared, except for a brief bit where he says of course I
won't ding you for forgetting a semicolon or whatever.

I really don't see any justification for his use of a whiteboard. He just says
it's normal, and that he does it too.

~~~
robotkilla
Ah thanks - i actually skimmed pretty fast through the article because I'm
busy and thought his reasons were for whiteboard testing. I still think on
site code tests are garbage too... and working in offices when we can easily
work from our homes. I like how most of build all this great technology to
connect ourselves through the internet and then think its somehow more
productive to work in an office setting.

------
vdnkh
_Practice_

On my first real software interview, even though I got 90% of the answers
correct, I didn't get an offer. I didn't ask specific enough questions,
constrain the problem, or quantify my reasoning to satisfaction. And the funny
thing is I knew I needed to do that. I had been preparing a while before the
interview, and knew I had to do everything stated in this article, but it just
went out the window. And I'm very good at doing this on the job. But at the
whiteboard I didn't even realize I wasn't _really_ explaining myself. I knew
the answer (more or less) and just blurted it out, happy to be correct. But
process is much more important. And it takes discipline to slow down and
explain yourself. Now when I'm practicing, I talk to myself while writing on
the whiteboard, and I have a little script I follow in the beginning of the
problem that ensures I spell out my assumptions, the input/output, and the
expected behavior of the algorithm. When I get myself in this mode of breaking
down the problem, I find questions just roll off the top of my head.

~~~
facepalm
I dunno - couldn't the interviewer just ask if they want those things from
you?

~~~
vdnkh
You're expected to ask them. It's a minefield, really. But it's really not far
off what I do on my job. When I get a spec I always ask questions like that.
It's just hard to come up with scenarios when you've been given an isolated
algorithm.

------
arihant
Why is this approach used? I have never, in my life, have coded on a
whiteboard while actually building a product. I draw, I brainstorm, I even
write plain English steps, but never code.

It's extremely weird that companies are trying to act like S.H.I.E.L.D., and
every interviewer thinking he is Fury. And they are almost always wrong.
You're recruiting to someone to do a job, not to transform them into
something. If they will likely never do something in the actual job, it is
mindless testing them on something.

Founders should be aiming to hire people better than themselves. Fury is
awesome for hiring Avengers, not field agents. And no Tony Stark is coding on
whiteboard happily.

> _It’s hard in part because you don’t have IntelliSense or syntax colouring
> or any of the other tools at your disposal that you normally do when writing
> code. I know that, and I’ll take that into account._

This is weird. In what conceivable situation would one not have access to
those tools on job site? Hell, I've seen a lot of programmers quickly check
API available to them in a new language before forming a mental map of it.

While the author may think he knows what he is doing. My personal guess is
that he is alienating a lot of amazing people. If you test Lance Armstrong on
his ability to ride a unicycle, you might miss out on him. That is essentially
what you're doing with whiteboard coding.

~~~
ericlippert
I take it into account by asking a problem that is so simple and
straightforward that you do not need google, intellisense, or any other tool
to solve the problem. As I mentioned in another comment above, I have asked
problems as simple as "add and subtract four numbers". A candidate who needs
to use Google to determine how to add and subtract doubles in C++ will not be
successful.

Now, perhaps I am alienating candidates, but first, I am very willing to
accommodate any candidate who wishes to demonstrate their coding skills to me
in some other way, and second, my primary goal is to prevent bad hires. If
good hires go to the competition, that's too bad, but it is way more important
to prevent a bad hire. What I am not willing to do is fail to test candidates
on their coding ability; I have had candidates -- some with advanced degrees
-- show up who had no demonstrable ability to solve practical problems.

~~~
arihant
> _I have had candidates -- some with advanced degrees -- show up who had no
> demonstrable ability to solve practical problems._

For real? I'm assuming you imply advanced degrees for reputable university?
From my experience in CMU, it is hard to imagine someone slip through the
system without an extreme command on general programming.

Maybe it can happen at a research focused Masters, but someone with a BS in
Computer Science from the top 5 should not flunk an interview.

~~~
ericlippert
Oh yes really.

I have had candidates with PhDs in computer science who had a deep
understanding of static analysis of programming languages, but who did not
know how many bytes were in a pointer on a 64 bit operating system, who
thought that there was an algorithm for compressing any 64 bit number into a
32 bit number, who could not describe the possible consequences of a buffer
overrun in C, and who had no idea whatsoever what a virtual function table
was.

Now, to be fair, as Dijkstra is said to have pointed out, astronomers are not
experts on telescope building. People with deep knowledge in one small area of
a field are often ignorant of other areas, even closely related areas. In
those cases it's even more important to get a sense for how the candidate
approaches problem solving, whether they can learn on the job, and so on,
because you know that they are going to be deeply in problem solving mode very
quickly when faced with their first real-world problems.

I hold up myself as a case in point; I helped build the JavaScript engine that
was in Internet Explorer in the 1990s, but know practically nothing about
HTML, the browser DOM, CSS, and so on. If I were interviewing someone like me
for a web developer position, I would have to be convinced that the candidate
could learn quickly.

------
serve_yay
Writing code on whiteboards is hard, writing code on an unfamiliar computer in
an unfamiliar room while a stranger watches on is hard, writing code in the
middle of a job interview is hard (and unrealistic since we never do that
during the course of normal work).

So maybe you should stop making candidates do it. Give them a coding test they
can work on in their own time, or whatever works for your situation.

~~~
jasonmp85
And how many employees doing these interviews can actually write code on a
board? Not to sound too wimpy, but holding your arms up like this is
physically taxing for the unpracticed. Unless you're pulling in a lecturer for
an interview, it's just not natural for an actual programmer.

And why would you want to disadvantage actual programmers when you're hiring
one? It just makes no sense. Whiteboards are for argumentation during design
discussions. They're great for high-level block diagrams and all that. They're
NOT great for long runs of text, and _especially_ bad for code.

If you're in-person, pair program. If you're remote, find a good online code-
friendy (syntax-highlighting, monospace) scratchpad and use it with a voice or
video chat solution. And if you can't schedule time with them, ask them to
submit a repository with a solution to a harder problem. If they need to
explain why they did something, that's what commit messages and READMEs are
for. If they don't understand that, that's a mark against them.

It's already enough of a conceit to ask someone to e.g. reverse a linked list
when they're practically _never_ going to be doing that in their day job. To
ask them to do so using a dry-erase marker writing with 4" lettering on a
whiteboard while standing is crossing into the ludicrous.

~~~
serve_yay
Well, part of my point is that the whiteboard isn't really the issue, it's
just the most egregious aspect of the situation.

You say if you're in person, pair program. But where, on what computer, doing
what, in what editor, etc? All these things plus the inherent pressure of the
situation make the experience unpleasant enough, and the results unreliable
enough, that you just shouldn't do it in my opinion.

~~~
crucini
I take your point, but I have been interviewed with the "pair programming"
concept and found it much easier.

It also tells the interviewer how you really interact with a computer.

I find the whiteboard stressful. I'm tempted to use short variable and
function names to save writing. I can't easily insert more lines of code. The
code tends to get cramped and illegible.

In a text editor I'm more likely to make huge changes as the concept evolves.

A significant proportion of good programmers use vi or emacs. I realize there
are outliers who just have to have Sublime Text set up the right way.

------
iamcurious
_A word of advice: writing code on whiteboards is hard. Practice!_

Yes. If you are able, try to get some experience teaching. If you do it well,
it will give you plenty of experience writing code while discussing its
relative merits. Hell, spend enough time with academics and you will get in
the habit of writing code on paper first and only typing it later as an after
thought.

And wait till you get one know-it-all student! They act like sufficiently
smart compilers, correcting both syntax and semantics. They will make sure you
follow what you teach!

All this sounds hard, but the curve doesn't have to be more steep than you
want it to. The world is full of programmers who could use a few minutes of
your time to understand that pesky algorithm that you know backward and
forward.

~~~
qmalxp
I totally agree. IMO it doesn't even have to be a CS course; my experience
TAing calculus helped immensely with whiteboard interviews.

I think it's the process of pacing yourself through the problem. If I see some
fancy integral, I might be able to solve it in one or two lines. But if I want
the students to understand, I'm not allowed to skip steps so it'll take more
like 15 lines, and I'll have to verbally explain each line as I write it. It's
getting used to switching back and forth between dictation and logical
process.

------
piyush_soni
Whiteboard tests are already stupid, but some companies take it to another
level. The last time I went to get interviewed by Amazon, they told me to
write a complete, syntactically correct, "ready to go into production" code (I
was literally told this). I didn't get that job.

They did even worse when my friend was interviewed by them. He was told to
write production quality code on a whiteboard, and when he did that, they
asked for an explanation, and clicked a photo of it through their smartphone
to evaluate it later, _probably on a real compiler_. Really, when you can't
even understand production quality code on a whiteboard by yourself, how do
you expect people to write it in a tense setting?

~~~
aniket_ray
The photo was probably clicked to attach it to some sort of internal candidate
feedback form. Photos ensure that the interviewer does not make a
typographical mistake while entering it in.

Also production quality code is usually interview speak for "Your code should
be more robust i.e. check inputs and return values from library functions. Fix
it."

------
zxcvvcxz
Here's a story. I interviewed for Amazon a while back, online whiteboard
(laptop + phone interview). They asked me to code up some esoteric binary tree
algorithm that I definitely didn't remember. In "real life" I would do the
responsible thing and google/wikipedia this algorithm, re-teach myself how it
works, etc.

But nope, gotta do it on the spot. Alright sure - open up a new tab (while on
the phone), google it, and proceed to rewrite someone's StackOverflow answer,
explaining it along the way. Now that I believe takes skill, especially since
you gotta fake out the interviewer and make your discovery process seem
"realistic".

Suffice to say, I decided not to follow up with them for the next interview.
If this is what they look for in their workforce, go hire kids who waste their
time memorizing "Cracking the Coding Interview".

I'd rather write useful software with my time, thank you very much.

------
MarcScott
Writing code on a whiteboard is something I'm perversely good at. It's because
I'm a teacher and not a developer, and I often end up shoving quick Python or
Pseudocode algorithms up on my classroom whiteboard.

I also encourage my students to code on whiteboards. I have a class set of
mini-whiteboards that they can use at their desks to jot down bits of code,
flowcharts or just their thoughts.

I've noticed when touring tertiary academic institutions (Edinburgh School of
Informatics for instance), that every room and office has whiteboards filled
with scrawled code. So maybe this is just a practice from academia that has
trickled down into industry.

------
genericuser
When white board coding is required, I really feel it is better suited to
allow a fair bit of psuedo code to be used in it. This article basically says
they will take into account the lack of things like InteliSense, but their
example is of what would be a pretty minor syntactical error.

I mean I guess I fail to understand why if you show that you know the
algorithms you are trying to implement, and the data structures needed to do
so, what does it matter if you rely heavily on auto complete to give you the
correct method calls off of those objects when programming?

I realize a programmer using auto-complete which knows the method signatures
well enough to not use auto-complete, will have a slight speed advantage while
developing over someone who actually needs auto-complete. But there have to be
better ways to test for development speed if that is truly your concern.

Similarly I realize the interviewer would like to see how you respond when you
can't remember or don't know something, do you get frazzled and frustrated or
do you ask questions. However there are definitely far situations you can
create to to watch for these type of reactions than simply expecting someone
to know the syntax of a language well enough to write it on a white board.

Honestly what am I missing?

------
dba7dba
IMHO, any interview (phone or onsite) for a tech job that rejects a candidate
because of some deficiency is found in technical skills during the interview,
whoever scheduled the interview is at fault. That manager/HR-person just cost
the company easily a few hundred dollars.

Such determination of one's technical chop should've been made well early in
the screening process, from past work or online tests or coding example (like
take home project type).

Interview process is expensive. It takes 1-5 hours of manhour from your
company. It takes similar or more from the candidate. Think about how much you
pay each engineer.

just my 2 cents.

------
jarnix
And it's even harder to draw on a keyboard :)

It's stressful to write code during an interview but it's necessary since it
really helps understanding how the developer thinks when he's trying to solve
a problem.

I usually ask candidates to write code on paper, or even speak the code they
want to write. If they know the algorithm but not the function names I don't
care. This test is done after the first part of the interview where the
candidate is given multiple questions so, usually, I already know if the
candidate is good or not ;)

~~~
genericuser
"it really helps understanding how the developer thinks when he's trying to
solve a problem."

How does it do this over watching them code on computer? Could you please
provide examples of how this helps more than say them bringing in their own
laptop (being provided with one for use if they don't have one) and you
hooking it up to another display and watching what they write as they write it
in the same room with them?

~~~
ericlippert
I have tried that as well in the eleven years since I wrote this article. It
is much more work for me to set up a development environment, get the
monitoring software working, blah blah blah, and there are many points of
failure, but if the candidate feels more comfortable doing it that way I'm
willing to do so.

The problems that I ask are so easy that it really does not make a difference
whether the candidate is writing on a whiteboard or typing on a computer; most
of the problems I ask can be solved in fewer than six lines of code. I am
using the code as a starting point for the conversation, not the end point.

------
exratione
It remains crazy that whiteboarding in interviews is even a thing. We don't
test to see how well candidates perform interpretive dance, and that bears
about as much semblance to real work in this profession as does a whiteboard
exercise.

[https://www.exratione.com/2012/09/whiteboard-exercises-
are-a...](https://www.exratione.com/2012/09/whiteboard-exercises-are-a-
terrible-way-to-investigate-coding-ability/)

------
nijiko
Best thing I've found is to get someone to tackle a problem you've recently
faced or are going to face and see how they handle it.

Not on a whiteboard, but with actual code and examples. Some companies will
pay for this, and others just take it as a part of the initiation process.

It really lets you see what people focus on, how they handle it (time, code,
style, design, etc), and how dedicated they are to the actual problems you
face.

------
zallarak
Agreed. I write a lot slower than I type, especially when writing a
programming language. This messes me up. I also tend to write a general
structure then insert code. Doing this on a whiteboard is hard because you
can't move text around, you can just erase it.

That said, with a calm mind and practice, its not that bad.

------
kstenerud
A number of years ago, I got into the habit of bringing my laptop to any job
interview. If I couldn't convince them over the course of the interview the
merits of writing code on a computer and running it vs a whiteboard, I didn't
accept the job offer.

------
ljlolel
Never write on the whiteboard: [http://www.jperla.com/blog/post/don-t-write-
on-the-whiteboar...](http://www.jperla.com/blog/post/don-t-write-on-the-
whiteboard)

------
spydum
really the whiteboard interview is about telling the story of development..
not solving the problem.

it would be interesting to see two scenarios up online in video format:

scenario 1: dev writes out very elevant well crafted/optimized solution
quickly and explains it and is done.

scenario 2: dev makes elaborate song and dance routine explaining the problem
space, then writing some code, then changing the code, then optimizing the
code. the whole time, very compelling/emotionally engaged and "passionate".

Have community vote on who is the better developer to hire. I have my
suspicion of who would win.

------
superuser2
I'd disagree with wanting candidates to be confident in their solutions. You
should be confident in a solution when the tests pass - and maybe, not even
then.

------
wolfgke
I really don't understand the hate that whiteboard coding has on HN. In
Germany, this is used a lot in the programming tutorials on universities. It's
not that there isn't a projector in about any larger seminar room. But most
exercise instructor will strongly prefer whiteboard coding for explaining how
to design an algorithm that solves the given exercise. The strong advantage is
that you can easily draw pictures at some other corner of the whiteboard that
illustrate the idea of the algorithm lines that you just wrote. This is also
the preferred way for students to explain their implementation of the
exercises. They could easily just show the source code on their laptop that
they implemented. But I (and many other students and exercise instructors) see
that the explanations are a lot more easy to follow if they have to build
their implementation step by step on the whiteboard explaining their ideas
thereby. On the other hand, if you have no idea how to solve the algorithm you
can still write a skeleton of the algorithm and draw pictures by the sides to
show where problems might occur.

Most exercise instructors would say that only really good students are able to
directly write an algorithm down into the computer. On the other hand, any
student should be able to draw, say, a flowchart, of the algorithm. If you
have done that (and are confident that it looks correct), _then_ you can write
a code snippet next to each box of the flowchart that implements (this is only
one example. There are exercise instructors that prefer other ways than
flowcharts. For example when you instead use recursion, there are other,
better, methods). This way you wrote down an algorithm using the flowchart as
an intermediate abstraction to simplify the problem.

It might be that in the US a different way is used to teach programming (I
really don't know which).

Also in the internship whiteboards were regularly used when discussing about
the best way to implement an algorithm (in about the same way they were used
in the programming tutorials with the only difference that once everybody
understood the idea, all got back to their computer to implement the
algorithm). I never had to whiteboard code anything in job interviews, though.

So I really claim that I wouldn't be really worse in whiteboard coding than if
I were coding on a computer. I also have reasoned why whiteboard coding is a
lot more comfortable in particular in the case when you don't have an idea how
the complete algorithm even has to look like (than things that you can be done
on a whiteboard, as drawing pictures, drawing flowcharts or writing down
recursion equations can badly be done directly in a source code editor). Thus
the only explanation that I have for the (nearly) universal hate of whiteboard
coding on HN is that many people (me too) have difficulties writing code under
stress situations (say, job interview). But this also applies if you write the
code on a computer. Thus I believe the hate on whiteboard coding is rather a
scapegoat for a lack of programming skills. If it were replaced by another
method of a systematic assessment of programming skills, they wouldn't fare
better (they just wouldn't have the scapegoat of whiteboard coding anymore).

