
Don't write on the whiteboard - ljlolel
http://www.jperla.com/blog/post/don-t-write-on-the-whiteboard
======
edw519
Sorry OP, I realize that you're just trying to be helpful sharing what's
worked for you and I appreciate that, but frankly, I hate posts like this...

I think the best preparation for any interview is to simply get good at what
you do. All the rest is window dressing that distracts from that goal.

Every minute spent practicing interviewing would be better spent building
stuff. The natural byproduct of this will be exercising those skills that will
be evaluated.

What you're proposing is unnatural and unnecessary. You're focusing on the
details of the process instead of the real issue of knowing your stuff.

Good interviewers won't care if you're fundamentally solid but a little light
on the presentation side. And they won't be fooled by a great presenter who is
weak under the hood. Sure, you may fool a weak interviewer, but what does that
say about the company you may be joining?

We all want to be solid in both fundamentals and presentation, but I prefer to
focus my limited resources on getting better than I am, not _appearing_ to be
better. Best to just be good, be yourself, and trust that it will show
naturally, no matter how you are evaluated.

~~~
barkingllama
I'm glad the author mentioned Project Euler... I've never heard of it. Anyone
else have experience with these problems? Is it a good way to improve your
development skills?

~~~
reledi
Here's a list of sites I keep for ACM ICPC preparation or problem solving for
fun:

<http://livearchive.onlinejudge.org>

<http://coj.uci.cu/OnlineJudge>

<http://www.spoj.pl>

<http://uva.onlinejudge.org>

<http://acm.timus.ru>

<http://acm.sgu.ru>

<http://acm.zju.edu.cn>

<http://plg.uwaterloo.ca/~acm00>

<http://cs.stanford.edu/group/acm>

<http://dwite.ca>

<https://www.facebook.com/careers/puzzles.php>

<http://code.google.com/codejam/contests.html>

<http://projecteuler.net>

<http://www.codechef.com>

<http://www.interviewstreet.com>

~~~
psykotic
You left out Berkeley's annual programming contest:

<http://www.cs.berkeley.edu/~hilfingr/programming-contest/>

The bottom of the page also has links to problem sets from a bunch of other
contests.

~~~
reledi
Thanks, I was unaware of that one.

------
random42
From an interviewer's perspective, the whiteboard gives me a chance to
intervene to correct, explain, or provide hints, to the interviewee sooner/at
the right time, which is not possible in pen-paper solutions, as I cannot see
what the interviewee is doing till she shows me her work, unless I sit at the
same side of the table as herself, which is odd for general
discussion/talking.

My advice to interviewees:- Practice on a whiteboard. It is not _that_
difficult.

~~~
ptmx
Perhaps I'm just neurotic, but I do find it uncomfortable to write code with
someone scrutinizing my work. When figuring out how to implement an efficient
algorithm, I find that it's often helpful to perform exploratory steps before
actually writing the algorithm. For instance, when I attempt a projecteuler
puzzle that I don't immediately know the solution to, I'll usually try to
compute the desired result for a few simple inputs, or I'll quickly write down
the first (naive) approach that comes to mind and then trace through it to see
where it fails, etc.

I know that those are all things that I can still do during a whiteboard
interview, but having the interviewer look at my intermediate work, assume
that I'm making mistakes and try to correct me tends to disrupt the process.
I'm confident that the algorithms that I'll ultimately produce will be good,
and I'm confident that I'll produce them at a good speed, but it will still
look worse to the interviewer if I write down a bunch of noise before
outputting a polished algorithm.

On the other hand, on paper, I can quickly churn through some of those early
steps and then show the interviewer a solid, finished product without them
having to see the crude intermediate steps. Again, it's possible that my
anxiety about this isn't really justified, but I can't help but get the
feeling that working in this way will leave the interviewer with a worse
impression of my abilities than if I have the option to "hide" the rough work
and just show them the output.

~~~
bethling
As an interviewer, I'd much rather see your intermediate steps - the messy
parts, etc. I feel like I can get a better idea about how you work and think.
Interview questions (for me) aren't about "can you solve this" they're more
about trying to see how you work. I ask questions about decisions you made,
and I like it if you can talk about what you're thinking.

Interview problems are contrived. I don't care if you stumble a little bit.
Heck, I'm always happy when I see someone start off the wrong way, notice that
something's wrong, take a step back and go a better path.

If you go off with a paper and pen and just give me an answer, I miss out on a
lot of that. And even though the anxiety might not show how you normally
interact (and I totally understand that) - I can't possibly get any sense as
to how you work in a collaborative environment.

I've never had anyone ask to do problems on paper instead of a whiteboard, and
I wouldn't refuse it to them - but I just get a feeling that I'd be less
likely to be inclined to hiring them - not because of the paper, but because
there's no way to see the things that I most like to see.

~~~
jebblue
That sounds more like a visit with Froyd than a programmer interview.

~~~
grot
Freud?

------
joshsegall
The title doesn't do the article justice. As an interviewer myself I think
it's terrible advice. Certainly if you think it'll make or break your
interview go ahead and ask to write on paper, but thinking through problems
and expressing them on a whiteboard is an important skill at a lot of
companies.

Many of his other points are good, although a lot of it boils down to being a
top notch developer and letting it show in the interview. Being a top notch
developer is the hard part, and good interviewers (at places a top notch dev
would want to work at) will typically identify your skills even if you don't
follow this specific advice.

+1 for using python--it's great for getting through coding questions quickly
and efficiently, allowing exploration of various twists the interviewer may
throw at you.

~~~
ljlolel
Thanks for not just talking about Whiteboards! That's just the hook and intro!

I agree. I think high-level planning and design is a great use of whiteboards
in the workplace. Code under time pressure, not as much.

------
danko
A pretty good array of interview tips which can be summarized as follows:

(1) Make yourself as comfortable as you can, so that you can:

(2) Make it clear what you're thinking and how you think (which is the point
of the interview).

I'm not signing on for the concept of always doing your interview in Python,
however. Do your interview in the language you're most comfortable in, unless
it's something so esoteric that it's likely to throw the interviewer off
balance. Python is a great language for these sorts of exercises _if you know
it_ , but don't force the issue if you don't, because then you're violating
(1) above. I know Python well myself, but I'd do an interview in Java because
that's "home" to me, and you need all the "home" you can get during an
experience as alienating as your standard interview.

------
joeyh
Seems to be a divide between those who like using whiteboards and not. I can
think of several contributing factors:

* academics vs non-academics

* those who enjoy thinking on their feet vs those who enjoy thinking in a text editor

* good handwriting vs not

* right vs left handed

Regarding the last, writing left-handed on a whiteboard means you're either
manipulating the pen uncomfortably from the far end, or you're smearing what
you wrote. You're also tending to obscure the audience's view of what you just
wrote with your hand, arm, and body.

I'm sure all of the above are part of why I prefer to avoid whiteboards, and
would be much happier with my laptop on a projector. Although if I'm
communicating with trusted peers I have no shame in putting up a smeared,
slanted, and mostly illegible scrawl.

~~~
dfan
It's funny, I think every interviewee who has apologized for their bad
handwriting has been at least 50th percentile in handwriting legibility.

------
revorad
Thanks for writing this up, it'll be quite useful to me.

I found your last line quite amusing: "I want to learn how to push the
boundaries of knowledge, not just apply what I learned in these books."

When I quit my PhD to do a startup, my thinking was the exact opposite: "I
want to apply what I know to solve real problems out there, not just keep
learning and write more books which no one will read."!

------
podopie
First, let me just mention that I think it's fantastic when others offer to
share their personal experiences with interviewing, particularly when what's
shared is unique and interesting to read or look at.

As others pointed out, there's more to this article than the whiteboard title,
and some great points (particularly a fan of the python one) are made. I can't
agree with the whiteboard concept, unfortunately. Maybe it's because of my
teaching background, but when I interviewed for a startup engineering position
a long time ago, they loved my whiteboard usage. It was clear, easy to follow,
and effective. In some respects, it's (part of) what got me the job offer.

That said, the main point between whiteboard or pen and paper: make sure you
can express yourself clearly to your interviewers. It was crucial in all the
essays I graded, and a key skill to attain no matter your profession.

------
dfan
I like seeing interviewees write on a whiteboard because I can see how they're
thinking and help them out if I see that they're running into trouble. The
point when I give a whiteboard question is to engage interactively with them
over the course of ~15 minutes while they solve a problem, not to sit around
and be handed a piece of paper at the end.

In addition, communicating with peers via whiteboard is a skill that is
actually handy in day-to-day work life; it's not just some artificial
interview skill.

~~~
ljlolel
So sit next to the person while they write...

~~~
bethling
The natural posture, position, and size of writing on paper discourages that.
It's also essentially impossible for me to step in and point to/mark up their
code (and then erase it). The paper takes away any of the collaboration that
can occur during an interview. Your code might be better, but I have trouble
seeing that you'd be able to project as a positive impression as if you used
the whiteboard.

~~~
ljlolel
Parents of children and teachers don't seem to have a problem with paper.

~~~
bethling
I don't have a problem with paper - I just feel like it would work against a
candidate - not because "Oh...they used paper", but because some of the things
that I think are signs of a good candidate don't show through.

I've never interviewed a candidate that asked me to use paper, so I can't be
sure - it's just my instinct.

It might be completely biased though - I far prefer to use whiteboards - I
love the space, I love how easy it is to erase without a trace. I can throw
thoughts up there and the manipulate them.

~~~
suneilp
What do you do when your too tall for the whiteboard because some short stubby
interviewer placed it lower than normal to accomodate his stubbiness.

------
GotToStartup
Great article with lots of valuable info in there. The part about the actual
whiteboard is almost irrelevant. Most of the comments here are getting too
worked up about that.

"Learn Python and use it during your interview." Python is expressive, a high
level and kind of writes like pseudo code. Just write pseudo code. The point
isn't syntax anyways.

"The highest value problems I know of are on Project Euler." I do enjoy
running through Project Euler problems but I have no evidence that's making me
better at my day job, only better at answering Project Euler problems.

~~~
ljlolel
Many companies (including the one in question) want to see actual code in a
language that they use at the company. The fact that Python happens to look
like pseudo-code is a bonus.

Maybe you already knew all the lessons in Project Euler, but for me, I became
a much better programmer. How elegant are your solutions? Have you tried
writing them in a different style than you're used to? Say, in a functional
style? With Haskell?

~~~
GotToStartup
But if companies want to see actual code in a language they use, then learning
python to use simply for interviewing wouldn't really work either right? So
your only options would be "use any language but not just pseudo code" or
interview for python jobs only.

Oh no, I certainly didn't know all the lessons and I haven't done all of them.

"How elegant are your solutions? Have you tried writing them in a different
style than you're used to?" That's a great point, so I suppose it's less about
the actual Project Euler problem, and more about optimizing, refactoring and
trying them in different languages.

~~~
ljlolel
> That's a great point, so I suppose it's less about the actual Project Euler
> problem, and more about optimizing, refactoring and trying them in different
> languages.

Exactly. Make it better.

------
MPSimmons
[Disagree]

Whiteboarding is a very, very valuable skill. The ability to effectively
convey your ideas to a group of people, while presenting what amounts to an
extemporaneous speech, is a tremendous asset.

~~~
gldalmaso
>> _is a tremendous asset_

That is also essential for the applied position?

~~~
MPSimmons
In the case of me hiring my replacement, yes.

------
Herring
Did anyone get the O(document size) solution? I can't see how it would work
without checking each word against the list.

~~~
larelli
At first glance I don't think you can achieve O(document size) without some
form of preprocessing. Each word in the vocabulary has to be looked at, so a
natural lower boundary seems to be O(document size + vocabulary size).

Also it is unclear what will count as an atomic operation. Although the
description reads as if word comparisons were counted, this makes for another
simplification, as words could be of arbitrary size.

Also: I only checked the HN comment section to see if someone got the solution
and I am amazed that others stuck to that part as well.

~~~
ljlolel
Yes, you use pre-processing.

I framed the problem in a very real-world scenario. Use that. It's not a trick
question. How would you solve my real-world problem efficiently?

------
zck
The author brings up some interesting points, but fails to back them up. Why
does he prefer not to write on the whiteboard? Why Python? [1] Why interview
the interviewer? Sure, there are reasons I can think of, but I'm not
convinced, and would like to know why he is.

[1] In later tips, he gets into some things that make Python good, but it
needs to be justified more, given that his advice boils down to "use Python
even if you've never seen it before".

~~~
seanmccann
I think the quote from the interviewer summarizes it best.

"Normally people write it in Java and it takes them a while and it takes up a
lot more space on the whiteboard. They spend a lot of time manipulating the
input string."

If you're more comfortable with Ruby, it would also be a great alternative.
Clean, readable code. You get to focus on solving the problem.

------
dkarl
_The interviewers don't care. Use paper._

Uh, yeah, we do care. Part of what we're judging is your ability to present
and explain your work. How you do your work is your business, but how you
share it affects the people you work with. If you think it's all about you,
then you're off on the wrong foot already.

~~~
Tooluka
We don't commit new code to whiteboards. We commit it to VCS. You know, with
such electronic thingies, called computers. And when my interviewers wanted to
collaborate they didn't find it too difficult with paper. Even sitting
opposite of me (and that is why large tables in conferences are evil).

------
fotbr
Use python even if you're a c++ systems guy. Or, you know, you could use the
language that's most likely to be used in the job you're applying for. If
you're a c++ & systems guy, interviewing for a c++ & systems job, c++ is far
more likely to be the language of choice for an interview rather than
buzzword-language-of-the-week, be it python, java, ruby, haskell, etc. Of
course, if you're interviewing at a place you KNOW uses a lot of python, then
yes, python would be a good choice.

Besides, most interviews I've had end up being a phone interview for knowledge
and skillset, followed by the lunch interview where they're more concerned
with finding out how you'll fit in with the existing team.

------
bdg
> Then take your solution and do it in half the lines. Now, read more of the
> Python docs (maybe read about generators and list comprehensions and
> decorators) and make it even shorter.

I don't agree with this. Shorter lines of code don't really express anything
beyond how cuthulu-inspired your code will read, and performance is very
likely to take a hit. Euler problem 2 solutions that are simply a for-loop
rather than take advantage of geometric progression are _slow_ and don't
indicate higher-level abstraction of problems or the tools to solve them.
Almost any programmer should be able to do the first 50 programs with random
brute-force methods that are only a few lines long, but that doesn't do
anything other than demonstrate you can have a computer add together numbers
based on an if-statement.

It especially doesn't show you know how to bring together technologies that
are useful for doing things such as building a website.

------
aoeuid
The poster is right -- don't write on a whiteboard. Instead, bring your
laptop, make the font bigger on your favorite editor, and write in that. I've
gone through many interviews like this, and only one interviewer insisted I
use the whiteboard. And I'm pretty sure that was largely out of wanting to be
fair to other candidates who didn't think to bring and use their laptops.

Since you will presumably be writing code on a computer when working at the
company, why not write code on a computer when interviewing with one?

------
drumdance
It seems a lot of what he's talking about is how to deal with anxiety. One way
to do this that I've found extremely useful is just to say "I've gotta be
honest, I'm feeling a little anxious about this." Not just in interviewing,
but in anything in life. If you are willing to be vulnerable, oftentimes that
allows you to breathe and the person you share the vulnerability with will
come to your rescue (i.e. help to set you at ease).

That said, _don't_ be needy. Just acknowledge your anxiety.

------
kabdib
I've done interviews both ways (paper and whiteboard), on both sides of the
fence.

It's never been a big deal.

I /have/ seen candidates fail because they insisted on using a laptop. But
these folks were typically very nervous about coding, and had essentially pre-
failed the interview in their head. Their laptop was a security blanket, a
totem that they hoped would sustain them, and it didn't work.

------
ww520
I don't know whether others are like me but I've spent so much time typing
rather than writing that my writing is rather bad. Writing on whiteboard is
actually easier than on paper. Perhaps the best is to bring a laptop and type
it out?

------
stcredzero
_Understand what you don't know, why you don't know it, have an interest in
it_

This strikes me as the fundamentals for what someone should look for in an
interview for a startup or research position.

------
sliverstorm
_You should always have paper and pen anyway to write down ideas_

Am I the only one who is not such a fountain of ideas that I can keep it all
in my head?

~~~
jc4p
You're definitely not alone. But, I've found that even if you don't do it, you
should still try.

During my last interview I brought along a notebook, the day before the
interview and the bus ride over to the office I wrote down any question that I
could think of in the notebook, even forcing myself to think of extra
questions.

It got people's attention, I talked with 6 pairs of people and each one
pointed it out in one way or another.

~~~
sliverstorm
Certainly take notes in preparation for an interview. Certainly bring a
notebook to an interview. I just don't see this whole "carry a notebook at all
times" thing.

~~~
stephengillie
Respectfully, what is the benefit to recording your notes and ideas on paper,
and using paper at interviews, instead of using txt files in the dropbox
folder of the always-connected smartphone in your pocket?

~~~
lutorm
It's sufficiently painful to express myself on the tiny keyboard that I tend
to avoid it. Not to mention if you want to sketch something.

------
readme
A hashtable need not have a "set key" or "get key" method. It only needs
get(key), and put(key,value)

------
lhnn
As a bonus to my upvote, I want to be clear: This is a great read. It inspires
people to learn algorithms, know how to back up your assertions, and be
confident with an interviewer.

------
MrMan
is the OP a professional employee/interviewee or something? the energy spent
preparing for (seemingly countless) interviews could have been spent working
on things s/he is passionate about.

------
dlevine
I have dinged people because they wouldn't write on the whiteboard. To be
fair, every time this actually happened, I gave the candidate the chance to
write his solution on paper, and I ended up dinged him anyways because his
work was sub-par.

At every company I have worked at, from two-person startups all the way to
Google, we have used whiteboards extensively. Most meetings and architecture
reviews are conducted in front of a whiteboard. The first thing I do when I
found a startup is to buy a whiteboard and nail it to the wall. Whiteboards
are a necessity for collaborative brainstorming and working together.

I'm not sure I agree with anything the OP says in this article. I think he's
trying to sound smart and rationalize the reasons he didn't get hired. I say
this not as a troll, but to provide constructive feedback. If you want to get
hired by a big company, you have to play by their rules. End of story. There
are a few exceptions (like engineers at Google without college degrees), but
they are exceptions - most people who work for Google or Facebook or Palantir
went to good schools, and did well, and wrote on the whiteboard during their
interviews.

~~~
georgieporgie
You sound like you have confirmation bias, and your whole point seems to be to
adhere to the status quo.

The notion that an engineer's ability can be discerned by willingness and
comfort at a whiteboard is utterly ridiculous.

