
"Can you solve this problem for me on the whiteboard?" - bascule
http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html
======
patio11
A minor heresy: If you're doing it right, there won't be a coding challenge at
the job interview. For that matter, there probably won't be a job interview,
at least not in any recognizable sense of the term.

I mean, the author is entirely right: skilled devs can write their own ticket
in this market. So, um, let's start doing that.

I also continue to think that "I have code on Github" is believed to be a
career enhancer not because this is actually true but because it is something
that is convenient to engineers to practice. In real life, the people whose
decisions matter a) often can't read code and b) almost always have better
uses of their time than reading code from someone who is, statistically, not
likely to be hired.

~~~
mindcrime
_I mean, the author is entirely right: skilled devs can write their own ticket
in this market. So, um, let's start doing that._

 _I also continue to think that "I have code on Github" is believed to be a
career enhancer not because this is actually true but because it is something
that is convenient to engineers to practice_

For what it's worth...

A while back Seth Godin wrote something about resumes being irrelevant, and a
lot of stuff about "personal branding," blah, blah, blah. It wasn't without
controversy, although I don't remember if it was discussed here on HN or not.

Anyway, here's an anecdotal data point for ya. I took Seth's stuff to heart.
Since then I've made it a point to do things like giving talks at Tri-JUG,
Tri-LUG, RTP Semantic Web Meetup, etc. And I do have code on Github (and a few
other places) and I do network a lot and a lot of people know who I am and
what I do.

Net result? When I got laid off from my then $dayjob about 2 weeks ago, I made
2 phone calls in my car on the way home from the office, and essentially had a
new job lined up within 2 hours. No resume, no interview, etc. Somebody knew
my reputation and when I said "I'm available" the answer was basically "Oh
hell yeah, we want you."

I did eventually send in a resume and do an interview, but it was really just
a formality to satisfy their HR process.

Also, they pointedly told me that I could skip even the formality of their
coding test, because "you have code online we can look at."

So yeah, my experience is, if you do the right things, and are good at what
you do, you can avoid a lot of the bullshit that's usually associated with
hiring.

~~~
euroclydon
Thanks for the feedback. I live in the Triangle too. There's plenty of demand
for developers here, with decent average salaries, but not great. So merely
getting another job is no great feat. What I'd like to know is, was it worth
it monitarily or do you think you could have got a similar job in a couple
weeks without all the networking?

~~~
mindcrime
Well, even without the networking and stuff, I'm reasonably sure I would have
eventually found something, yeah. The open questions, to me, are "how much
longer would it have taken?" and "would it have paid as well?"

But my point was more that I was able to shortcut a lot of the usual rigmarole
that it takes to get hired. And to the extent that I did go through any of it,
it was obviously just a formality and there was no pressure or whatever, like
you might normally expect. It's also just a nice ego boost to know you're
wanted enough to where you can lose one job and have another lined up in a few
hours.

------
raganwald
I suspect the author and I agree on the general idea, but the argument seemed
forced. If I’m interviewing a chef for a Mexican restaurant, of course I want
them to cook for me. But I might ask them to draw stuff on a whiteboard, like:

a. A shopping list and schedule

b. diagram the layout of a kitchen used for making Mexican food

c. A recipe for Mexican food

The OP’s story is mixing two different things: Questions outside of the domain
and the whiteboard vs. programming. I think they’re orthogonal.

For example, what if he was asked to go into the kitchen and prepare Creme
Brulée? Clearly, that would be as bad as being asked about the ingredients.

~~~
bascule
It's a hard metaphor to pull off. Cut my some slack :)

The real point I'm trying to make is just if you want to test somebody's
ability to write code, give them a computer, don't make them code on a
whiteboard.

If you're actually using a whiteboard to assist in visualizing something or to
help explain a problem, great! But that's quite different from being asked to
write down code.

~~~
ctdonath
Last interview before my current position, the group of simultaneous
interviewers did the usual "on this whiteboard, write a program to do X." I
waved off the pen, pulled out my notebook computer, started typing, and said
"don't mind me, just continue on" and wrote the program while fielding other
questions, and asking for clarifications on requirements. The offer was not
long in coming.

------
ap22213
Great fable. And, I really sympathized with it and laughed out loud; I've been
there.

But, we should add a few missing details to Jim's world to make it more
accurate:

1\. Being a chef is one of the most lucrative jobs for a person with a
Bachelors degree or less.

2\. The world is saturated with recipes and good food. Further, the most
impressive recipes in the world are shared freely on the Internet. Because of
this, it's common for non-chefs to download the best, most hyped recipes and
slap them together to make an inspiring meal or two.

3\. Therefore, many non-chefs try to go after chef jobs. Pay is great, and
just download recipes from the Internet. Easy money, right?

4\. Furthermore, world-class restaurants are in a never-ending recipe-
invention arms race, trying to out-class the common fare. To them, chefs that
can just cook recipes are useless. They need chefs that can invent new,
impressive recipes on the fly with whatever ingredients that are on hand.

5\. Because of the success of the best restaurants, every restaurant owner
believes that their restaurant is potentially world-class . Therefore, they
believe that they also need a team of the best inventor chefs to craft their
menu.

------
mikeryan
A white boarding exercise is only as useful as the person running it is.

A quick example if you ask someone to design something in ruby (creme brulee)
and they say they only know Python (Flan) and you don't say "okay show me it
in Python" you're totally doing it wrong - you either have the wrong candidate
or you're asking the wrong questions.

I've mostly only gotten value out of white board questions when interviewing
folks in architecture or design roles (its a great way to just visually
explain relationships) or for testing familiarity with algorithms. I've never
used them for checking language syntax.

~~~
bascule
Whiteboards can be invaluable tools and are a great way to explain problems.
Writing large amounts of code that might require a great deal of revision is
better served by a computer.

My best experiences in job interviews on a whiteboard have been ones where the
interviewer is also on the whiteboard, writing just as much as me if not more.
My worst experiences have been where the interviewer was sitting in a chair on
the opposite side of the room from me.

~~~
marshray
My favorite job interview question was this one. The conference room had a
projector on the whiteboard with this:

    
    
        char *c[]= {"ENTER", "NEW", "POINT", "FIRST", };
        char **cp[]= {c + 3, c + 2, c + 1, c};
        char ***cpp= cp;
        main()
        {
            printf("%s", **++cpp);
            printf("%s ", *--*++cpp + 3);
            printf("%s", *cpp[-2] + 3);
            printf("%s\n", cpp[-1][-1] + 1);
        }
    

I just happened to be recently studying all the operator precedence rules and
other subtleties in that code, so I got it all right. (Probably wouldn't do as
well today :-)

But mainly it was there as a point of discussion to see how you approached
such code.

And like most conference room whiteboards, most of the pens were dried out. I
tossed those into the trashcan.

~~~
georgemcbay
"But mainly it was there as a point of discussion to see how you approached
such code."

One would hope that the expected answer was to approach it by way of promptly
deleting it, replacing it with something readable, and then finding the person
who wrote it and kicking them in the shin at least 8 times.

~~~
marshray
How are you going to know how to replace it unless you can figure out what it
does?

------
gentle
Analogies are not infinitely applicable.

I don't ask interviewees to be able to replicate a complete algorithm in a
language they don't know, but I do expect that they can implement
straightforward logic and requirements in _some_ language.

They need to follow basic standards. They need to show that they are competent
programmers. They don't need to necessarily write something that will
absolutely run / compile on the very first pass.

cooking creme brulee != writing code

~~~
rgraham
I think the OP is okay with the use of the whiteboard, but it should be used
as a complement to writing code in a semi-familiar environment.

There is no claim that cooking is equivalent to writing code. The claim is
that writing code is rarely done on a whiteboard (Perhaps design,
architecture, or some logic back-and-forth but rarely code.) and that
interviewees shouldn't be expected to perform well at something they don't do.

------
roguecoder
I'll bet solid money most chefs wouldn't have any trouble with the analogy
he's given. The only difference is that actual chef interviews would probably
also ask for a full meal plan and wine pairings.

I think some of the whiteboard-focus came out of places where whiteboards
are/were used frequently in the development flow. Whiteboards are effective
ways to communicate design and architecture, even algorithms. In the Olden
Days(tm) it was not uncommon to walk through an office and see code on the
boards.

I don't know exactly when we got out of the habit of explaining our code,
though I imagine better tools and the Agile code-as-its-own-documentation
movement had some part in it. Still, I think it is hard to argue that it is
irrelevant.

CS is relevant to many coding jobs. Maybe not code monkey or some HTML jobs,
but for most high-quality software developer positions one does need to
understand run times, recursion, OO and command line tools to do the job
effectively. If the only way you can talk about those things is on a computer,
to the computer, you may be a fine lone coder but you will be ineffective as a
team mate.

------
harryh
Any attempt to criticize the "code on a whiteboard" style of interviewing that
doesn't even engage with the fact that many of the best software engineering
organizations in the world use this method is suspect from the very beginning.

If this style of interviewing is so awful, then how do these companies have
such great engineering teams? I'm not saying there aren't reasonable
approaches here, but you must try or your essay isn't worthwhile.

~~~
dpritchett
Bill Clinton presided over the dotcom boom and some historically high NYSE
numbers. Does that make him an economic wizard?

It's not hard to see a parallel between Clinton's economic policies and
Google's interview policies. Both get credit for outcomes that may have been
caused by other factors entirely.

~~~
harryh
I agree that this is possible. I'm just saying that if you don't engage with
this issue at all in your essay (as the OP failed to do), then your essay is
missing a very key issue and should be largely discredited.

------
ChuckMcM
Loved the allegory, and sorry you didn't get the job at Google if that was
what you were hoping for :-) The good news about your fictional chef is that
if he had managed to trick the pastry chefs into hiring him by being able to
talk about them, he would have been miserable at work where the chefs were
constantly covering up their lack of experience making Mexican food by
debating the merits of manufacturing cream vs heavy cream, and decrying
pasteurization. When it came time to nominate sous chefs the number of
pastries made (or lack thereof) would be held against poor Jim. Instead the
chef who didn't know where to buy cilantro from and started growing it in his
office will get the nod because he has a variant of this herb named after him.

------
jack-r-abbit
I think 9 times out of 10 I would fail a whiteboard coding exercise based
solely on my bad handwriting... which is even worse when done with a fat
marker on a vertical surface. In my day-to-day work I am rarely (if ever)
required to actually write something down that others will need to read... so
my bad penmanship is a non-issue. If you want me to whiteboard something in an
interview perhaps provide a computer projected onto the whiteboard (or what
ever tech you have) so everyone can see and let me type my response while we
talk?

I have a keyboard... and I know how to use it.

------
Jay42
I believe that this kind of thinking is what differentiates the companies that
are successful in the long run from the ones who can create a one shot
product; and I'm not sure the OP is on the right camp.

To take an internet-famous example, Kevin Rose went on the record to say that
one of the major failings at Digg was the fact that they hired anyone who
could code in PHP in the beginning, but when a PHP-based solution stopped
being the answer, they were left over with a bunch of PHP developers who
couldn't do anything but that.

If your mexican restaurant finds out that the most successful part of the
business becomes making dessert (Mexican at first, but then onto other kinds
of styles), then they would be happy to have picked someone who can actually
cook something else than just Mexican food.

I think the whiteboard tests are an attempt at figuring out the capacity of
the interviewee to abstract the problem instead of solving it the
fastest/usual way. In my experience, the ability to abstract is very closely
correlated to the ability to adapt to new situations (and code better in
general)

~~~
jxcole
I agree that variety is nice, but the underlying thrust of this article is
that programming on a whiteboard is an inferior metric to programming on a
computer (at least that's what I took away). It also makes very little sense
to have a Mexican restaurant that ONLY cares whether it's Chef's can cook
desserts.

Whether or not you can do bit twiddling is far less relevant to a PHP coding
position than being able to write PHP. This is not to say that a bit twiddling
problem could be added as extra credit, but you should be far more concerned
with their understanding of PHP.

So, to incorporate both of your interview styles, it would be a good idea to
have the chef cook Mexican food, desserts, and some other stuff rather than
just cook a single Mexican dish. This would give you a more complete view of
his qualities. Then a decision can be made based on a variety of data rather
than a single data point.

But flexibility can be too extreme. I've seen job postings for people who are
good at programming AND can photoshop good UI. To me these are such completely
unrelated fields that it would be very hard to find someone who is good at
both. You would probably have better luck hiring two different people for
those positions.

------
softbuilder
I recently wrote about my similar experiences (minus the nice analogies). Be
warned, it's a long, long post (2 parts, actually) but details the experience
first hand. <http://www.youell.com/matt/writing/?p=785>

------
huhtenberg
I wouldn't dismiss the whiteboard altogether, there are some questions that
are easier to answer by scribbling than by programming, but an obvious and
important take away is "be nice to the people you are interviewing, because
you may end up working with them."

------
snorkel
I've stopped asking candidates to write code on the whiteboard because that's
not how coders work. I instead ask questions like "describe how a hash table
works" and "when do you prefer to throw an exception instead of returning an
error code?"

------
jtchang
If the question is about architecture and design, whiteboards make sense.
Drawing pictures, connecting things together, understanding the larger realm.

If the question is about code give me a damn editor and I will show you what I
know.

------
amirf
This is a brilliant article. True for the most parts.

However, I think that actual coding that relates to the job in discussion is
important. This doesn't contradicts the idea in the article though.

------
BinaryMeltdown
At the company I am in, being able to express solutions on a whiteboard is
fundemental. I have turned down applicants who were brilliant programmers
because they could not express their solution on a whiteboard (I find this is
highly correlated with a - "I can code therefore I don't have to talk to
people" persona, which is fine in some companies, just not ours)

Nearly every software project begins in a room with a whiteboard, we often
spend days mulling over massive whiteboard drawings with lines, boxes, psuedo
code etc. But once we have finished with the whiteboard everybody goes away
and the code is written by multiple developers, in parallel and the end of the
week (sometimes the end of the day) it is finished and it all integrates
perfectly.

Repeat the above over the lifetime of a larger system, and the hours spent
expressing the ideas on the whiteboard save 10 times themselves in
implementation and test.

Some developers hate this approach and see it as robbing them of their
"artistic freedom", but the fact is, large scalable solutions aren't designed,
developed, tested and integrated by lonewolf coders (at least not as a rule).
By being up front, pooling ideas, knocking them down and arguing them out in a
"public" setting I have never seen a software project fail, be late, over
budget or not meet requirements (at least as far as a project can meet dynamic
requirements) - we call it the House diagnostic approach - throw ideas out
there, see what makes sense - only differences are the domain (not medicine)
and the fact that "House" becomes the group.

As a note: I don't expect candidates to be perfect at expressing themselves,
or even have any experience with white board design at all. But if they can
grasp the problem domain (and they should, all the sample problems I set are
really basic (design a system to collect and sample some basic census survey
data i.e. design a record structure (a class, a database, a file - i really
don't care), define an efficient way of accessing the data (hash table of
classes, database queries, a novel file directory structure - again don't
care, I want to see that they can grasp and spout ideas about), and define
some algorithms to work out averages, aggregates, max, min range, sort etc.
(testing basic algorithm knowledge, and they they can apply this to their
solution).

The breakdown of the last group, of 400 applicants:

300 were rejected in the paper sift because they failed the paper
test....(like the above, but on paper, simpler and you have as much time as
you want to do it.....there is a serious lack of good talent!)

79 were failed at the first interview because they had problems explaining
themselves on a problem like the one described.

18 were failed at the second interview because they were not deemed to have
enough experience in computer science, mathematics or physics (or whatever
domain they were supposed to be expert in)

3 passed and were offered places, and have settled right into the company.

~~~
lutorm
Sounds like a good use of whiteboard, but it seems you agree that you don't
use the whiteboard to write _code_?

------
nirvana
The best jobs I've had in my career, by far, were with the places where the
interview consisted of sitting down and talking. In fact, one notable one, I
was interviewing with the founder (this was my first startup though back then
they were just called small businesses, and this was just a fast growing small
business). We talked about stuff, including technical stuff, some problems I'd
worked on, etc. Not only did he not ask me to write any code, ever, nor had
they seen any code of mine, but by the end of the interview he told me they
were going to make an offer. The thing is, this was my first real interview,
and my first interview for a full time programming position. I'd written
software part time, but had been pursuing physics as my field previous to
this. So, it couldn't have been that I was a good interviewer... I had no
skill at that point.

They were so happy with me after the first year they gave me a %40 raise.

Meanwhile the worst, most excruciating, took all day and I didn't get the
chance to have lunch I was promised, interview where I met with 9-11 (I lost
count actually) people, and had to write code for _every single one of them_ ,
ended up also being for the company that was the worst to work for, where I
was surrounded by mediocre programmers and the management was absolutely
incompetant.

I think if I made a graph with one axis being the amount of programming
required in the interview process, and the amount of suckage at the job in the
other, those experiences would show correlation.

Anecdotal of course, and I have theories as to why, but that's been my
experience.

~~~
digitallimit0
My experience has been exactly the same as yours. My current career and
company that I'm entirely excited be a part of never had me write code once
during the interview process. I graduated an accredited college with a high
GPA and had programmed in a student position for 4 years, at a startup for a
couple months and a contract-to-hire governmental position for 1 month. Not
the craziest experience, but I think it's silly to be so cynical to assume I
can't write a simple fizzbuzz program after all of that.

~~~
jshen
You would be very surprised by how many people there are with n years of
experience and a masters in comp sci who can't write fizzbuzz. In my
experience it s close to 50% with a sample size of about 50 candidates.

------
georgieporgie
Typo at the beginning: "dependent and reliable" should probably be "dependable
and reliable".

