
Hiring without whiteboards - sugarpirate
https://github.com/poteto/hiring-without-whiteboards
======
jonasvp
I'm responsible for hiring developers at our company based in Berlin, Germany,
and found it best to have a guided interview about the candidate's work
experience and interesting problems that she/he solved. I never understood the
whiteboard hazing/CS trivia that are so widely discussed on HN since it seems
extremely disconnected from the actual work that's being done.

That said, I'm always surprised how many candidates cannot even point to one
problem they worked on they found interesting or one solution that they're
proud of.

We worked with an HR consultant to develop a interview guide in the form of
certain questions that we make sure to hit during the interview in order to be
able to compare between candidates and make an informed decision.

However, we're small and not in the US. Anyone have experience with other
companies in Germany/Europe? How does the typical interview work over here?

~~~
et-al
> _That said, I 'm always surprised how many candidates cannot even point to
> one problem they worked on they found interesting or one solution that
> they're proud of._

It could be that this technique favors people good at telling stories.

Personally, I'm a horrible storyteller. If you were to ask me what I did over
the weekend, I'll offer some facts like "oh, went swimming in a river and Bob
lost his hat, but we found it later. The water was nice." Whereas Bob could
easily regale you with stories about the epic hunt for his hat and throw in a
punchline in the end.

If I didn't know that you'd be asking for solutions I'm proud of, I might draw
a blank at that moment. Granted it's an interview setting and these _are_ the
questions one needs to prepare for. But if given the choice between speaking
about myself or whiteboarding, I'll take the whiteboard.

I've always preferred math over history for that matter. It's easier for some
of us to apply processes than to recite chronologies.

~~~
clarry
> > That said, I'm always surprised how many candidates cannot even point to
> one problem they worked on they found interesting or one solution that
> they're proud of.

> It could be that this technique favors people good at telling stories.

Or people who think they're impressive. I know I would've been able to point
out many problems and solutions I found interesting and were impressed with
when I was 15. Today, not so much. The more I know, the less impressed I am
with myself, and more and more stuff just feels "routine" and nothing special.

It could be that I'm just not impressive. At all.

~~~
YCode
I'm not a "look at me!" kind of person, but here's what has really helped me
with these kinds of interviews.

Keep a daily journal of what you work on. Nothing fancy, just stop by once a
day religiously and add a few notes on what you did, what meetings you
attended, who you spoke with, etc...

Save your evaluations and especially any award packages you or your team might
get submitted for. At least where I work both are your supervisor's attempt to
make you look as good as possible.

Then, when you're job hunting review your notes and bullets and collect the
ones that sound the best and perhaps ones that have numbers assigned to them
(size, savings, productivity, etc..)

Preferably you'd memorize these few stories about yourself, but if you must
you could also bring a notebook with prompts to remind you.

~~~
Declanomous
My grandfather used to do this. He had notebooks filled with what he did every
day of his career. It's really cool to be able to go back and look through his
notebooks and see what he was doing in April of 1971.

My notetaking is not as rigorous as my Grandfathers, but I do something
similar. Every month I make a new manilla folder with the month and year on
the tab. Each week I write down every project I'm working on and every meeting
I have. If someone brings me a new project I put it on the sheet. Every note I
take a meetings and during projects goes in that folder.

At the end of each week I go through the notes from that week and write down
anything interesting on that week's note sheet. At the end of the month I go
through all the notes and write what I accomplished on the front of each
manila folder.

It makes it really easy to keep track of everything you've done, without
consciously keeping a journal in the moment. It's also a really easy
organizational system. When someone asks, "What did we do for [x] in the
past", all I need to do is flip through my folders looking at the front for
anything that rings a bell, rather than trying to keep up with a tagged
organizational system.

This probably doesn't work if you don't have a file cabinet though.

------
kelvin0
Imagine this. You are interviewing for a job, you walk in a room with 2 people
who hand you over a sheet with a few problems. They ask you to write the
solutions on the whiteboard, while they wait for you to complete.

Not a word is said, they are clicking at their laptops, and staring at the
whiteboard, as waiting for the genie to pop out of a bottle. All the while
your mind is frozen and stuck in a bad loop.

This lasts an hour, you are barely able to complete parts of the problems and
are frozen. Of course this affects your usually creative and sharp mind.

The torture lasts an hour, time's up! You shake their hands, as a kiss of
death, and head out. As you are walking back, all the answers to all the
problems they wanted you to whiteboard, come rushing like a torrent in your
mind. Too bad, another 'botched' technical interview.

This is my experience as a battle tested developer who is shipped many
products and has been programming for the love of computers since the age of
12 (professionally for more than 15 years). I am not going to be working at
Google any time soon (not that a Google job really matters to me).

~~~
udev
It is also a cultural thing.

I observe that anglo-saxon peoples teach their kids to voice their concerns,
needs, wants, and opinions, and to expect (!) results from this. (Compare how
american kids behave at airports, train station, and public places with kids
from other countries, e.g. french speaking countries).

This helps them approach situations in life with a healthy dose of self-worth
and the baseline state of mind that if something is wrong it's not their
fault.

In contrast, many other cultures teach their kids that it is
impolite/crude/disrespectful to bother adults with your half-baked thought, or
(God forbid) unexpected wants, or complaints.

I come from a culture where you are expected to moderate your verbal output
when addressing your superiors (e.g. teachers, boss, etc.). You speak out only
when you have something worthy to say.

Example:

I had trouble going to "office-hours" when at university in North-America. I
always got the feeling that I am bothering the prof, and it is my duty to
study more to understand the material, and I should not take his time when I
merely did not understand something.

My anglo colleagues seem to not have such qualms. Their thinking is more along
the lines of "I don't understand (not my fault), it is his job to teach me
(most likely his problem), he has to explain this better, I pay for tuition
after all...".

I am happy to have unlearned some of the above things.

But generally, I find the speak-your-mind-at-the-white-board-while-we-watch
interview tailored for cultures where kids are taught to be vocal, and are
difficult for equally intelligent people from other backgrounds.

~~~
adrianratnapala
People are downvoting this, but the difference in cultures is real (though I
wouldn't say it is confined to anglos). But udev might be exposing a case
where the "anglo" culture has a genuine advantage.

Engineers really should communicate clearly about technical stuff. People
solving complex problems really should concepualise their approaches clearly,
ideally so that can be expressed in words. People really should reach out for
help when blocked.

And if Anglos find it easier to do those things, then good on 'em.

~~~
Apocryphon
I don't think it's just a communication thing. It's also a confidence thing.
When a culture places emphasis on self-censoring behavior, then the candidate
is less likely to express themselves for fear of censure.

------
ninjakeyboard
What's with all the whiteboard backlash? I ask simple questions and expect
people to be able to write code unaided to express their idea. Not "implement
a linked list" or "write quicksort" but basic "You have two arrays - find if a
number exists in both arrays" sort of thing, primarily to reason about runtime
complexity, and to make sure they can actually write code.

If you tell a candidate to prepare, they should be able to come in and do
this. If they can't write some simple code unaided, then I don't want to work
with them. I was a copy-paste programmer once too.

~~~
ciqsteve
Whiteboarding itself is a skill. What I learned the hard way:

\- There is no insert. If you need to go back and insert a line of code
somewhere you must either erase all the code below it to make room (then
rewrite said code), or you draw a line from the insertion point to somewhere
else on the white board and write the code there. For the former you waste a
lot of time. For the later the code quickly becomes hard to follow.

\- There is no context driven autocomplete or quick method lookup. If you
spend your entire day coding in one language and have done so for the last >3
years you should be fine. If you code in multiple languages and spend time
with other tasks (devops for example), you might not realize how much you rely
on this.

\- The white-boarding process works well (given previous two caveats) if you
code in a linear style. If you code iteratively the whiteboard is not your
friend.

My recommendation to someone starting the interview process. Go buy a small
whiteboard and use it to code solutions to interview questions you find
online.

~~~
ryandrake
All your points are good--and they are part of the overall problem with
whiteboard coding: A whiteboard is not even close to a realistic modern
development environment.

How many times, for your job, have you had to code up a solution to a problem,
even a trivial one:

1\. Just given to you 5 seconds ago

2\. With no access to documentation (paper, textbooks, offline or online
resources)

3\. With no access to mentors or colleagues

4\. With an editor crippled as you described

5\. Have to get it right within minutes?

6\. And then have to defend your code against someone who's had plenty of time
to think about the problem.

I can tell you, throughout my programming career, the answer is "never".

~~~
wilkystyle
This, to me, is the most important point. We make such a big deal about making
sure our tests actually test the thing we care about; why aren't we doing the
same thing with our interviewing processes?

------
bogomipz
I would like to see a compilation of companies that aren't requiring a "coding
project" as part of their interview process. I much prefer to write on a
whiteboard as part of an onsite interview than to do a "coding project" for
every single company that "might" be interested in me.

My experience lately has been an immediate request to complete a coding
project right after speaking to a recruiter but before speaking to anyone
technical. And perhaps the height of absurdity I have even had automated
emails saying "thank you for you interest we invite you to complete this
coding challenge/project."

Are you really expected to do one of these now for every single company you
send your CV?

The whiteboards seems far more respectful of people's time at least.

~~~
meowlicious
I am interested in this too. I recently failed netflix code review because I
used java 7 instead of java 8 which apparently showed them I don't keep up
with new technology (even tough the question asked me to pick any language on
jvm.) Other reasons given to me were that i used maven instead of gradle.

[https://medium.com/@meowlicious99/my-software-engineer-
inter...](https://medium.com/@meowlicious99/my-software-engineer-interview-at-
netflix-259bb94e5f46#.6482pbjyh)

~~~
hocuspocus
> all my open source code is written in java 8 for him to look

That completely defeats the purpose of a small, self-contained assignment like
the one you were given. And your code isn't even in Java 7 (no diamonds), I
think it was a legitimate remark.

~~~
meowlicious
You think it would be helpful to let the candidates know what they would be
evaluated for in the coding assignment.

I would have dazzled them with java 8 if I knew I was going to be rejected a
based on that :D

I was under the impression that this was the usual algorithm/data
structure/complexity rigamarole, not show us latest language features.

~~~
bogomipz
Yes this patently absurd. I am guessing you weren't allowed to discuss your
code or choices with anyone either correct?

------
vinhboy
I think coderpad.io is the modern day equivalent of a whiteboard.

It's nice that you get REPL and a keyboard, but the unnecessary pressure of
being watched, critiqued, and timed are all there.

My mind just goes completely blank whenever I am put in this scenario.

Are we programming or defusing a bomb?

~~~
akanet
Hi. I'm the guy that made CoderPad. I bootstrapped the product out of nothing
because of _terrible_ candidate experiences older purely textual collaborative
environments provided. I _sincerely_ believe CoderPad gives you much more room
to breathe than many alternatives. There are a few reasons for this:

1\. You get to introspect the environment. I've had lots of candidates forget
whether certain objects support simple methods (map, sort, join etc). CoderPad
lets you perform quick tests to make sure.

2\. You get to debug how you would _normally debug_. Whiteboard interviews
basically rely on the interviewer saying something "Are you suuuuure there's
no bugs on, say, lines 10 through 12?". I find this incredibly stressful as
both the interviewer and candidate. CoderPad lets you run the damn thing
yourself and see if it says what you want it to say.

3\. Compared to probably the next most relevant comparison, graded homework
assignments, I think CoderPad's free-form format is much more forgiving. As a
candidate, I've definitely wasted hours trying to get some hidden automated
test suite to pass with no feedback as to what sort of failure was
encountered. CoderPad blends code evaluation with live feedback from the
interviewer.

Yes, social pressure can be daunting for many candidates. I don't think this
is something you can avoid in a live interview in general. I think you can get
pretty good signal from project submission from candidates, but at the cost of
_greatly_ increased time spent by both candidates and interviewers. For many
people this may be a worthwhile trade and I think additional options are good,
too.

~~~
vinhboy
Regardless of how much your software has made me sweat, I still think it's
great software. My comment was more about the interview process, not your
software. Good job creating it. I wish it was free... Haha...

------
DigitalSea
The problem with whiteboards, is they're not reflective of real life. When was
the last time you can honestly say you used a whiteboard to solve a
programming problem instead of Googling and ending at a StackOverflow question
with a great answer? I've never used a whiteboard for programming. I've used
plenty of whiteboards for things one level back; planning, prioritising and
visualising task related things.

The reality of programming is, these days everyone Google's their problems.
Sometimes you end up at StackOverflow or sometimes you find yourself on a
random blog or official documentation. Occasionally you ask a coworker for
help, but the ego a lot of developers have to be smart means most feel
intimidated to do so. And sometimes you just bang your head against your desk
until things start working.

Whiteboard and highly technical interviews that expect you to know high-level
computer science concepts are tilted in the favour of graduates who are
freshly minted from whatever respective educational institution they graduated
from.

~~~
exDM69
Tech interviews are not reflective of real life regardless if there's a
whiteboard present or not.

Whenever I've had a whiteboard programming interview, it's always been a
trivial problem that's a smoke test for "can this candidate actually write
code or is their CV faked". I think it took somewhere between 5 to 15 minutes,
which I consider to be rather well spent time compared to spending hours or
days on a take home project or anything bigger.

The only time I've been given a take-home assignment I refused to do it
because I was extremely busy at that time (finals at uni). The employer gave
me an offer anyway. Someone else made a better offer, though (based on a
whiteboard session).

The whiteboard is not a good way to assess the level of programming skill of
an individual. But it's a good binary indicator of whether they possess _any_
coding skills. If the result is yes and their resume is good, experience is
relevant and maybe there's some GitHub or other code they can share, that
should be enough to consider a person to be an able programmer.

Like any tool, the whiteboard can be misused. The task should be rather
trivial and the time should be short. The purpose should be to weed out the
people who have faked their resumes or are applying to programming jobs even
though their talent is something entirely different.

~~~
baddox
> Whenever I've had a whiteboard programming interview, it's always been a
> trivial problem that's a smoke test for "can this candidate actually write
> code or is their CV faked". I think it took somewhere between 5 to 15
> minutes, which I consider to be rather well spent time compared to spending
> hours or days on a take home project or anything bigger.

That sounds pretty reasonable, but I don't think it's the norm. I had an
interview over two afternoons with 5 or 6 different whiteboard coding
challenges, each around half an hour and each much more substantial than a
smoke test. They were things like parsing and evaluating a string with a
simple arithmetic expression like "2+3*4+5" or taking a phone number and
enumerating every possible alphabetic representation (2 is "a" "b" or "c",
etc.).

Google has example whiteboard interview questions on YouTube, and one of them
was writing a function in C++ that takes an array of integers and a target
integer and calculates whether some subset of the array sums to the target
integer.

Not the most difficult things ever, but hardly smoke tests, and pretty
annoying to whiteboard in my opinion.

~~~
exDM69
I completely agree with you. Once you go past the 15 minute mark, the
whiteboard is no longer a good way to do programming aptitude testing. It's a
good smoke test, but doesn't really work beyond that.

Of the three examples you mention, I think only the phone number alphabetic
representation is a reasonable one to do on a whiteboard.

All the 5 to 10 whiteboard interviews I've had over the years have been smoke
tests. This is in Europe, and I got the impression from this thread that it's
a common smoke test in Europe and Americans tend to have longer whiteboard
interviews.

------
nostrademons
It's funny, whiteboard interviews really would be a better discriminator for
founders than employees. They test confidence rather than competence (or
technically, competence + confidence). The former is incredibly important for
founders, but the latter is probably what you care about more for employees.
And yet founders almost never do a whiteboard interview, yet it's standard for
technical employees...

~~~
scarface74
My view is that you can't have competence at a certain level without
confidence - unless you're just an easily outsourced code slinger. I'm often
at a whiteboard explaining architecture, ideas, etc. How do you do that
without confidence and some semblance of emotional intelligence.

~~~
pseud0r
There is really no comparison. Explaining architecture, ideas etc to your
colleagues has pretty much no resemblance to a whiteboard interview, where you
have several people staring at you and judging you. One is a discussion the
other is a test, they compare like having a beer with a colleague is like
holding a speech in front of a bunch of stranger.

~~~
dexterdog
When an interview is not a discussion, but rather a test, it is a bad
interview.

~~~
scarface74
Now that I think about it, I wasn't asked a single programming question when I
was interviewed for the job I have now. I was asked architectural, process
improvement, soft skill questions. That's probably why I chose the job I have
over other offers. It was more of a discussion and by the end of the
interview, I was joking around with the hiring manager and said something to
the effect of "I'm already assuming I'm going to get the job. When am I going
to hear back from you?" He started laughing and said soon.

Another interviewer told me at the end of the interview to submit an
application and they can get an offer emailed to me by the end of the day. We
did a collaborative white board design session and spent a lot of time just
talking.

Either all of the job offers I've gotten have been mostly just discussions or
I talk tech so much I can't tell the difference between an interview and a
typical day at the office.

~~~
pseud0r
Most interviews I've been to have been the same. I was talking about the ones
where you have to solve some tricky algorithm questions at a whiteboard while
someone is staring at you. I have no problem doing that in front of my
colleagues, but find it difficult to do at a job interview.

------
ibejoeb
It really is terrible. Companies need to accept this. You're sitting behind
me. Or beside me. I can smell your breath. Or you're on a webcam. It's
voyeuristic. You've already solved this problem. Perhaps you even designed it.
Your talking is breaking my concentration. This is not how I work. It's
probably not how you work either, and if it is, I think we're done here.

Now, if a company insists on an adversarial process, there are better ways to
do it. The nature of the problem is given in advance. Both the subject and the
evaluator go in blind, and they both do it.

~~~
SomeStupidPoint
You know what I call it when a coworker is reading off a document and
harassing me for not knowing the thing they're clearly looking up as they go
along?

A toxic work environment.

Of course, I believe a significant number of those "interviews" are hazing
meant to find excuses not to hire or perpetuate H1B scams.

------
wollstonecraft
The main purpose of whiteboard is to decrease the liquidity of job search for
engineers, thus depressing wages. After a few years of doing design docs and
copying protobuf fields, the median engineer at a top company would need a
month of prep to be able to pass whiteboard interviews again. Much more
effective than secret no-poaching agreements.

~~~
jonahx
While it may have the effect of decreasing job liquidity, I don't see how that
effect could be the main purpose unless you believe companies are mass
colluding. Because the company _running_ the interview is highly motivated to
find a good candidate quickly and reliably.

A less intriguing but probably more accurate reason is that finding good
people is hard, nobody really knows how to do it, whiteboard interviews
provide a rough filter, and they're what everybody else does, so we're gonna
do it....

~~~
crasco
You mean collusion like this?

[http://www.latimes.com/business/technology/la-fi-tn-tech-
job...](http://www.latimes.com/business/technology/la-fi-tn-tech-jobs-
settlement-20150903-story.html)

It was happening, only more blatantly than is suggested here. Of course they
are all motivated to find good candidates, but they are also motivated to keep
their existing folks. Decreasing liquidity and mobility serves the latter
purpose at the expense of the former.

~~~
PaulRivers
Yeah, that happened in 2010, they got sued for agreeing to not try to recruit
programmers from rival companies. Right after that we saw these long tortuous
white board interviews introduced which serve the same function but without
them getting sued over it.

------
koja86
OMG it's happening!

I was always puzzled by how unrelated metric used for hiring is to actual work
at many companies. I don't mind algorithmic brainteasers - on the contrary I
would absolutely love to solve such problems at work yet those seem to be
scarce. I also don't mind other types of developer work - be it more research
or architectural oriented or "just" coding.

But I am not happy learning something different for interviews every few years
and then forgetting it over the course of next period of day to day work.
Feels like a waste of time and is confusing in regards to what one would
actually do in certain job.

------
wolfgke
Why the universal hate for whiteboard interviews? I studied computer science
at a German university and it was expected that in the exercise groups you are
able to solve the exercises that you prepared on a whiteboard from the first
semester on. If you did not solve it sompletely you still had to whiteboard-
code the parts of the solution that you were able to and improvise the rest.

For more complicated algorithms I still love to draw lots of pictures before
implementing them.

I can understand that people complain that they have to solve tasks (on a
whiteboard) that won't have to do much with what they will do at the job. But
this has nothing to do with whiteboard interviews, but with badly chosen tasks
(say: data structure brainteasers) for the job interview.

------
tamalsaha001
I have a question. When you hire complete freshers out of school, how do you
interview them without asking for CS stuff? In my experience, fresh undergrads
usually do not have any real world experience.

I have experimented with short take home projects. This drastically reduces
the available pool, since great freshers can get job in other places with
whiteboards interview. Also, there is a sense that interview process is used
to get people to do free work.

Also, non whiteboard interview processes are extremely time consuming. Non-
whiteboards interviews will be better. But as a matter of practical
experience, I have found it to be the only viable option for hiring fresh
undergrads.

~~~
dagw
Ask them what they studied and what their favorite courses where. Ask them
what they found interesting. Ask them what kind of problems they can see
themselves working on. Ask about what kind of projects they did and what they
found easy and hard about them. Ask them some general programming questions.
And by all means ask CS questions as well, but don't only ask that, and don't
make them carry more weight than any other questions.

~~~
tamalsaha001
You will be surprised how often people with good grades will have good answer
for these questions. But can't write dual for loops.

I agree that asking people to write dynamic programming problems are not good
interview questions. But if the job requires primarily writing code, I think
it is fair to ask people to solve coding problems with loops, conditional
statements, hashtables, etc.

------
lordnacho
Main main gripe with whiteboards is that it's hard to add extra lines.

If you're writing a loop for instance, you might code up the per-item logic
first, and then you remember you need a loop variable. Which there's now no
space for, because in a normal coding environment you can just insert the line
where it's needed.

It makes me feel like I need to have solved the whole problem before writing,
and that's just not how coding happens.

------
Kiro
Am I the only one who thinks the pressure a whiteboard adds is actually
something valuable? In my last job there were a lot of situations where you
had to solve a real problem under extreme pressure. People who couldn't handle
it simply weren't cut for the job.

I don't think all interviews should use it but for us it was good for
filtering out candidates who would not perform in those situations.

~~~
learc83
In my experience, if you're regularly coding under extreme pressure, something
is wrong.

Whiteboard coding is also a different kind of pressure. I can't imagine a
situation where someone who already knows the answer is watching over your
shoulder critiquing you while you work on a problem.

~~~
fernandotakai
> In my experience, if you're regularly coding under extreme pressure,
> something is wrong.

right? unless you are in downtime mode, there's really something wrong with
your schedule/deliverables/tasks.

writing code is not a race, it's more of a marathon where you have to be at a
healthy pace to get to the end, otherwise you will not be able to finish.

~~~
Kiro
In an ideal world, yes, but for a company on a tight budget it's not that
easy. When the alternative is bankruptcy you don't have much choice.

------
on_and_off
Just ran through 2 complete interview cycles without touching a whiteboard
once.

Got a great offer from both and accepted one of them.

I strongly prefer a coding project to a whiteboard. It is still a bit
artificial, but it is way closer to my actual work.

------
alaaibrahim
Have you ever tried to bring a laptop to an interview, and asked to use it
instead of the whiteboard? Believe me very few would object.

------
listentojohan
It was not really a whiteboard exercise, but I once had an interview at which
we went through some of my previous work (code-ish) on a whiteboard. I was
mostly for structure, and I think that's a good example. Also there was a good
relaxed atmosphere, so it was more a point of discussion. Got an offer.

------
therealmarv
Whiteboard interviews are important. Reason:
[http://i.imgur.com/oM9yCym.png](http://i.imgur.com/oM9yCym.png)

~~~
PaulRivers
Ha, that's great!

------
ry_ry
I'm seriously tempted to make one of our technical interview questions "you're
creating a technical test for role XYZ, how would you structure it" and see
what the candidates come up with!

Would be interesting tbh.

~~~
scarface74
That would be a great question for a tech lead.

------
allenleein
Please add Jane Street.

[https://blogs.janestreet.com/what-a-jane-street-dev-
intervie...](https://blogs.janestreet.com/what-a-jane-street-dev-interview-is-
like/)

~~~
Volt
Make a pull request.

------
zerr
I'd like to have a separate list for companies that do _paid_ real-world
projects instead of CS riddles.

~~~
glibgil
Weebly

------
nallerooth
As a follow up to the first interview, we give promising candidates a quite
simple task to solve at home and then send back via email the next day. This
is used both for some basic evaluation of developers skills (whether they
actually solved the problem, did they catch the small oddities hidden in the
data set, did they document and write tests, etc.) and as something to discuss
during the second interview, in which the candidate talks to one or two
developers.

I also did a second code test, which I got to do alone on an offline laptop.
The test had a time limit and it was designed in a way that you should NOT be
able to finish it on time. This was communicated to me several times before I
actually sat down in front of the laptop. The goal with this test is to see if
a person can solve problems under stress, and if the person writes decent code
that works, or just hacks something together and moves on to the next step -
leaving a trail of bugs.

Overall, I think this has worked out great for us, but it might not be a good
process for everyone.

~~~
jpalomaki
Some time ago somebody mention in HN a process which sounded pretty good and
fair. For promising candidates:

1) Meeting where you are presented a problem and asked to immediately give
your thoughts on how you would approach it.

2) Some days, for example weekend, to work on the problem. Candidate gets a
monetary compensation for this time.

3) Next meeting where you present the solution.

Yes, there's always a risk that somebody will get somebody else to write the
code, but having to explain before and after reduces the risk. Paying for the
work shows you are serious about the recruitment.

~~~
mikulas_florek
> Paying for the work shows you are serious about the recruitment.

In that case candidates should also pay companies to show they are serious
about the position

------
whatwasmypwd
Is pair programming really that different from whiteboarding?

~~~
pmiller2
More specifically, I would say "interview pair programming" isn't really "pair
programming." When pair programming, it's not one person evaluating the other,
under an artificial time constraint.

~~~
whatwasmypwd
Can you really have any other kind of pair programming in interview context?

~~~
pmiller2
Precisely.

------
scarface74
I don't see a problem with whiteboard interviews. I've been to a lot of
interviews where they will ask me to explain an architecture and I ask _them_
to do they mind if I draw it out while explaining it.

I've spent so much time in my career explaining architecture it's second
nature for me to diagram while I'm talking.

During a whiteboard coding session in an interview, I would do some code and
some pseudocode.

But at this point in my career if I saw that the interview was focusing more
on coding than architecture/development process/automated testing that would
be a big red flag.

------
storafrid
If it lasts longer than 20 minutes, you're doing it wrong. But more
importantly, are we talking about hiring a security expert? Or hiring for a
product development team? Or hiring for the devops team? Context is rarely
given in the "whiteboarding issue" discussion, e.g. at HN. I currently hold
candidate interviews for a solution architect role, and I certainly don't want
to hire someone who can't hold a whiteboarding session with a client or their
partner's SME.

------
donpark
Whiteboard should not be the focus. If interviewer just shared whatever
technical problem they're trying to solve and asked the interviewer to share
their insight as a peer, then it's up to the interviewee to use the whiteboard
or not. Frankly, I think this is best done over email so interviewee has the
time to think about the problem.

In short, companies should approach interviews like free consultations with an
expert or peer.

------
NTDF9
I personally love whiteboards...but only for discussion of ideas. But
interviewers seem to use it only to dock points.

"Oh this guy solved the problem on the whiteboard with good syntax but he uses
new and delete. Must be a bad programmer."

I think docking points on whiteboarding just reflects how bad interviewers are
at judging skills, possibly because they themselves suck at self-awareness and
skills beyond their domain.

------
scottishfiction
Fog Creek is listed. I once interviewed there and was asked to calculate the
volume of a cylinder. Have they changed there approach?

~~~
quotemstr
Calculating the volume of a cylinder is trivial.

~~~
jotato
What does that have to do with solving problems? If you can't do it off the
top of your head, a quick search will give you the formula and then you plug
it in. Questions like this make me not accept a job offer for a place.

~~~
rsfinn
In general I don't like questions like this either, but this particular one
seems designed to test your wits if not your memory: if you don't happen to
remember the formula, you can quickly derive it. I bet if you said out loud
"It's the area of the end circle times the height of the cylinder", you
wouldn't have to go any farther.

~~~
scottishfiction
No. I said exactly that, and provided the formula for the area of the circle,
and was still asked to do the calculation.

------
mustafabisic1
This is great. I would add [https://toggl.com/](https://toggl.com/), but I'm
just a silly marketer and don't have a github account. btw not affiliated with
toggl whatsoever - just a fan :D

------
d--b
It looks like many companies in this list use the take-home project approach.
The take-home project however is not a replacement to the whiteboard session,
as they're not meant to screen at the same level. Once you're given a take
home project, you're almost in. It happens when the recruiter really likes the
person and wants to dig further with a real life scenario to see how that
person would perform.

The whiteboard session is a way to spot people who can't code early in the
process.

------
vertak
I work remotely and sometimes interview new potential hires. Does anyone have
some suggestions for how I could imitate whiteboard questions without actually
having a marker and surface available to me or the candidate? It's a little
awkward to ask them to write on a piece of paper and angle their camera so I
can see what they're writing! Is there any good software that can emulate
this?

~~~
gwbas1c
I do this all the time. What I do is make sure that the question, and anything
that I would want to write on the whiteboard, is typed up ahead of time. Then,
I use a teleconferencing program that supports sound, screen sharing, and IM.
(Gotomeeting works well for me, but there's plenty others that work well too.)

In the actual interview, I IM the written parts of the question to the
candidate. Then, I ask the candidate to share his/her screen, and use a
program like Notepad or Textedit to complete the question.

It's useful if the candidate copy/pastes my IMs into Notepad / Textedit. Often
I've provided a sample API that the candidate needs to program with.

I discourage using an IDE like Visual Studio or XCode. (They get in the way
when you're just trying to quickly express an idea.) Most candidates "get it"
that I'm just trying to see how they think and approach a problem.

Some candidates just feel more comfortable in an IDE, though. Other times,
though, when a candidate uses an IDE it shows that the candidate will get too
bogged down in details to communicate; or that the candidate really doesn't
understand the language that he/she claims to be proficient in.

Edit: In the context of the article, I'm a HUGE fan of whiteboard coding. It
tells me a lot about the candidate. Being on both sides of an interview; a
successful whiteboard interview has more to do with how the interviewer plans
the question and his/her expectations about what the candidate will answer. A
whiteboard interview isn't there to determine that a candidate can think of a
tricky algorithm; it's there to judge coding ability for very obvious problems
with well-known APIs.

Where I think the industry needs to go, though, is a universal certification
that demonstrates competence. Doctors have to go through this, thus doctors
don't need to demonstrate competence when interviewing for a job. That's
handled by the impartial 3rd party.

------
hyfgfh
Let's agree Hackerrank sucks. Develop a shity solution in a very limited time,
using ES5 and no libraries for JS, waste time parsing your input where the
first element means nothing and the other must have the type converted several
times....

If you really want to test a candidate, give them unlimited time, a "real
problem" and something that they don't know.

~~~
Taylor_OD
Why something that they don't know? (Actually curious)

~~~
hyfgfh
Most of your work is to learn stuff, to figure out solutions for new problems.
However some people keep themselves in their safe-zone, avoiding new kinds of
tech or solution. I belief that a good developer will like the feeling of
frustration when learning something that they don't know, that a bad piece of
code will make then uncomfortable.

The skill that I look for in another developers is the ability to learn stuff
that they aren't trained. This way I know that they will be able to solve new
problems, to find better solution for old problems. By testing then in
something that they don't know, I will see if they are open to learn new stuff
and able to apply new concepts, and ask how they felt about it later.

------
artf
"Build MVPs for startups", from Popstand, is amazing

------
golemotron
Whiteboards are MacGuffins for hiring conversations.

------
zj45499
So what's considered to be "Pair programming", compared to whiteboard?

------
hasenj
Using the presence of whiteboard questions as a metric for interview quality
seems rather pointless to me.

Whiteboards questions can be very good or can be very bad or anywhere in
between. Just like any interview question in general.

I for one prefer whiteboard questions to generic open ended personal
questions.

Good whiteboard questions can quickly assess whether someone knows the basics
of programming or not.

Open ended questions only judge one's ability to tell stories.

~~~
feedjoelpie
Early in my programming career, I got a whiteboard question where, after being
asked my hobbies, I was asked to diagram an electric guitar on the whiteboard.
I don't know that it was a particularly good question. But all this sabre-
rattling against the whiteboard in general just seems like a silly
distillation of a legitimate critique down to its stupidest form.

Even when it comes to CS algorithms questions. Yeah, asking someone to
whiteboard quicksort might be bad, might optimize for the wrong things for the
actual job.

But should it be a red flag that someone expected me to be able to do a more
basic operation, that I've more or less purported to do professionally and
efficiently, on a whiteboard on the spot?

[Edit: At my company we don't really do whiteboarding. We pre-screen with a
time-limited open-book, open-internet test in advance. This helps account for
candidates knowing how to quickly read/research/apply openly available
information.]

~~~
Declanomous
That reminds me of an interview I had for a sales position. The guy man asked
me how to tie a shoe. I actually really thought it was an interesting
interview question, despite not being strictly sales-related, because teaching
is a really big part of sales.

I like that guitar question for a similar reason. Someone once told me that
you can't program something you don't understand. Being able to break down a
complex topic in to atomic parts is the difference between someone who can
program, and someone who can develop applications that solve problems.

I'm an analyst rather than a developer, but most of my value comes from being
able to communicate information to other people. I know there are people who
are better than me at programming, or statistics, or modelling, etc. However,
I know that I can be incredibly successful in any given role if I take the
effort to learn as much as possible about whatever I'm analyzing, and if I
focus on communicating the information as clearly as possible.

To that point, I'm really proud of the fact that the man who interviewed
called me afterwards to say that I had given the best instructions for tying a
shoe he had heard in 30 years of asking that question in interviews. That
being said, I can see how someone who is a nervous interviewee would resent
questions that seem designed to trip them up.

------
douche
I haven't used a whiteboard in five years. Some people seem to love them, but
I just don't get it - in any situation I might use a whiteboard for, I have
more effective tools that I can use instead.

There's nothing like having to pull out your phone and take snapshots of a
whiteboard because people can't be bothered to use something persistent.

------
edblarney
There's nothing wrong with white-boards, it's how they are used that matters.

~~~
ratsz
I agree, although I prefer a physical computer or shared session to
whiteboard. I always tell interviewees that they can use pseudo-code or make
up functions as long as they explain what they are intended to do. This takes
the pressure off of knowing specific language constructs and leads to better
overall assessment in my experience.

------
hasenj
There is absolutely nothing wrong in principle with whiteboard questions.

~~~
collyw
I was far better at these straight out of university, as thats the sort of
short assignments we got given.

15 years later I am a far better coder (I class myself as a full stack
software engineer now) but I haven't needed to implement the sort of solution
that they ask for in years (except in interviews).

------
746F7475
Meh, if you can't even handle a tiny whiteboard situation how are you going to
handle any deadline pressure? It's not about knowing the right answer off the
top of your head, it's more about how you work and approach the problem.

Sure some bad companies expect you to be able to write something very specific
on the spot, but thous are pretty rare imo.

~~~
SomeStupidPoint
In what way do you think whiteboards are like deadlines? I honestly don't
understand this line of thinking.

It's not about "pressure", it's about the fact I'm an introvert and do poorly
at composing while speaking. My brain requires time to focus inward to
formulate complex thoughts, and interrupting any time I pause narrating
doesn't give me that time to think.

I've literally never had it be an issue in my career, because deadlines happen
on the order of days to months and in real life conversations it's acceptable
to pause talking for 5 minutes. (Heck, in real life, it would be _rude_ to
talk the way you do during an interview, because it wouldn't give the other
person a chance to share _their_ thoughts about the problem.)

~~~
746F7475
>My brain requires time to focus inward to formulate complex thoughts, and
interrupting any time I pause narrating doesn't give me that time to think.

So basically what you are saying is that you are some kind of snowflake that
requires it's own room to concentrate and be productive and you can't even
think while doodling on a whiteboard.

In my books that counts against you, that doesn't mean you are straight out,
but it definitely makes you a liability to some degree.

~~~
SomeStupidPoint
Not even remotely.

What I said is that I share a trait with about 25% of the population, more in
software, where I can't do my best composing if I'm narrating at the same
time. By "time", I mean 30-120 seconds without having to speak.

In actual development that doesn't matter: pauses to compose an answer are
fine in conversations and most work time is individual anyway (even in open
offices).

I do note, however, you didn't actually answer my question: in what way is
whiteboarding like real work deadlines?

~~~
746F7475
>in what way is whiteboarding like real work deadlines?

hurdur, what is stress, I dunno. Why is everyone on this site suffering from
autism?

~~~
dang
We ban accounts that post like this. If you can't comment civilly and
substantively, please don't post until you can.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

