
Engineering whiteboard interviews: yay or nay? - lynnetye
https://www.keyvalues.com/blog/engineering-whiteboard-interviews-yay-or-nay
======
bradenb

      VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer.
    
      No, not at all. Whiteboard interviews test one thing
      well: How well does a candidate code on a whiteboard.
      Engineers on my team never have to code on a whiteboard
      (whiteboards are really bad at running code), why would I
      make candidates do something that I don't ask the
      engineers already on my team to do?
    

This comes close, but I think the real issue that most of these reasons aren't
hitting on is that software development is typically done asynchronously.
Whether it's a whiteboard or a computer connected to a projector or TV or a
live peer coding session it doesn't matter: if done in the interview, it puts
the candidate on the spot in a way that they rarely (if ever) will be on the
job. Developers typically are able to take time by themselves or with
trusted/known colleagues to solve a problem. There are very few opportunities
to get over performance anxiety related to coding in front of others that we
don't know.

~~~
remoteorbust
> Whiteboard interviews test one thing well: How well does a candidate code on
> a whiteboard.

What if you consider part of someone's job to be communicating concepts to
people, possibly with the help of visual aids and diagrams?

I hate this concept that if it's not typing code into an editor then it's not
"real work".

I absolutely communicate with my coworkers using a whiteboard and pseudocode.
I reject the idea that being put on the spot is necessarily "artificial". To
the contrary, I think that the number of engineering jobs where you can assume
you'll never be put on the spot or have to communicate complex ideas verbally
or visually is relatively low.

Now if this particular skill isn't interesting to an employer and they'd
rather spend the time talking about some other candidate capability, that's a
whole different story.

~~~
timr
It's bizarre to me that you think that whiteboard coding tests
"communication", in any way. It's not like a presentation, or anything. It's
one-sided combat where someone with a secret tries to get someone who doesn't
know the secret to regurgitate the secret, on the spot, while pretending that
s/he didn't memorize the secret in advance while cramming a great big
"Cracking the Programmer Secret" book to prepare for the entire silly exercise
in Kabuki theater.

If you want to test communication skills amongst programmers, I dunno...ask
them to write something in coherent English. Or here's a crazy thought: ask
them to document some code. I guarantee that 80% of working "rockstar coders"
will fail (but not before whining, crankily, about how unfair it is that you
would actually make them do such a _useless thing_ , since, y'know...never
actually _documents_ anything IRL, dude).

Programmers like whiteboarding because it lets them believe that interviews
can be reduced to purely objective functions, and because GooAmaSoftBook does
it. They're too scared to deviate from the pack, lest people think they aren't
as "elite" as everyone else.

~~~
remoteorbust
> It's bizarre to me that you think that whiteboard coding tests
> "communication", in any way. It's not like a presentation, or anything.

I feel like we're probably at an impasse if I can't convince you that a
whiteboard is a decent medium to communicate ideas around datastructures and
algorithms, but I appreciate your point of view.

I can only say my experience, which I hope you will take into account as one
anecdote. I don't read books about "cracking the coding interview" or do
leetcode or hackerrank. I left school 14 years ago or so my stash of cs
trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews
where I come up with at best a naive solution.

And yet I've received offers for fairly senior engineering positions at Amazon
and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard
interview isn't even around the code, although that's a small part. Most of it
is analyzing the problem, discussing constraints, discussing tradeoffs,
walking through data structure manipulations, drawing arrows and boxes, that
kind of stuff. Some code, maybe 30% of the interview. I just keep having this
experience where nobody wants to play the gotcha game, they want to know how
well I can communicate while solving a problem and they think they get that
information out of the interview (I agree with them).

That experience makes it hard for me to understand a viewpoint that believes
that whiteboard interviews are about memorizing secrets in advance.

~~~
sidlls
Have you considered that your experience interviewing at these places might
have been atypical?

Every set of interview prep material I've seen from Facebook, Amazon and
Google recruiters asking me to interview in the last 3 months has included
links to things suggesting "cracking the coding interview" is a good start and
pointing to similar docs otherwise.

------
privacypoller
All of these interviewing "tools" (or tricks) attempt to be time/cost
efficient proxies for doing the damn job, and they all suck.

* Whiteboard coding is awesome for software development shops that don't actually own computers or use punch cards to load programs.

* Shared coding environments with a time limit works well when you want to double screen for someone who can also diffuse suspicious packages that arrive at the office

* Riddles and puzzles are good when your workplace has a chicken coop, an office fox and you can't figure out how everyone can go for lunch without leaving the fox alone.

* Behavioral interviews are appreciated by candidates who took Psychology 100 back in school for an easy A.

* Take-home tests go over well with the huge population of talented software developers who can't find a job and have loads of time they want to spend decoding the operational cost of a bubble sort

The only thing I've seen that's at all realistic and effective is a very
short, __paid__ project. I did a two-day one for Indeed (ironically one of the
worst promoters of all this bullshit) and a 4-hour one for my current
employer. The payment doesn't even have to be market, it's more important as a
signal to candidates that the company values your time.

I ask for 3 things from perspective employers:

1\. value my time like you value your own (both the number and composition of
your interview steps)

2\. keep me updated as to where we're at in the process and when the next
stage/decision will be made

3\. Move forward in the process in a timely manner. It should not take more
than 2 weeks from when you initially contact me to the process concludes.

I've never gotten more than two of the above from a single organization, but I
will someday, and I'm betting that a company that treats potential employees
that well will treat actual employees better as well.

~~~
vultour
Riddles are the worst, I was recently asked the "You have a 5 litre and a 3
litre container, how do you get 4 litres" question (never heard it before).

It's so simple to figure out if you're on your own and just play around with
the idea. When asked on the spot I just kept thinking "hey these people want
an answer NOW, don't make them wait" while feeling their stare, and couldn't
figure it out without help.

~~~
tluyben2
I guess if you are old enough you'll know that one from the movie. Doesn't
mean you remember how they solved it (because what did I care at the time?).
Nothing to do with programming unless someone asks you to write a short
program to figure out the most efficient (least steps) on how to do it. Behind
a computer.

~~~
batteryhorse
Yup. Bruce Willis and Samuel Jackson were able to figure that one out. It
can't be that hard. They were under a lot of pressure as well.

------
nybblesio
A regular viewer of my daily Twitch programming stream (link is in my profile)
asked me to solve a problem he was asked to whiteboard. He wasn't asked to
draw diagrams or write pseudo-code so they could learn how well he
communicated. He was asked to write _the code_ and it was heavily implied that
it must compile and run -- even though whiteboards don't do that.

Here's my attempt:
[https://youtu.be/6LHqrxrC6Uo](https://youtu.be/6LHqrxrC6Uo)

I solved the problem, with an IDE and a compiler. I communicate during the
entire exercise. It takes me over 2 hours. Granted, I debug it, so that takes
extra time. (Can't debug on a whiteboard!) I had to take one break. On top of
this, I've solved this kind of problem before and it still took me more than
the 45 minutes you're likely to get in a whiteboard interview.

And I try to cover all of the "hot topic" points I know the interviewer is
thinking about: size .vs. time tradeoffs, iterative .vs. recursive, etc.

If I had to solve this problem on a whiteboard, in 45-60 minutes, with the bar
being "it must run"....I would fail.

I guess that makes me a poor programmer. Instead, I'm a grumpy old man who is
really tired of all this fraternity hazing bullshit.

~~~
kmike84
I got an impression that just specifying the input data took almost 1.5 hours,
because of C++ and a decision to have it as a graph, not as a matrix. If an
interview is in Python, one would write something like ``grid = [[1,0,0],
[1,2,0], [0,2,2]]``, and be done with that part.

Probably you got exhausted after doing all these preparations and debugging
issues not related directly to the algorithm. I'm not sure the final solution
is correct, it is not tested on a graph with multiple connected segments of
the same color. It looks more like a convoluted way to count colors globally,
discarding standalone colors, if I understood your solution properly.

~~~
drharby
Thats the fun part 'to me' about mastery of cpp.

Sure you COULD use a graph, but using a different code abstraction to
represent the idea of a graph is much more pragmattic and maintainable, of
course that varies with application.

Im reentering interviewing phase right now, and its funny revisiting these
problems with a new lense. The mind is very plastic and its exciting, so far
as things to come.

Total nerd out moment :v

------
jackcosgrove
I think an under-tested aspect of software engineering is the ability to
research solutions on the internet.

Just give people a search bar and ask them to solve a problem outside their
comfort zone. See what terms they use and how quickly they can arrive at a
useful link. No pseudo-code or architectural diagrams needed. Just a link with
a plausible solution. Because that's how most learning on the job actually
happens.

~~~
jpindar
If I were interviewing that would absolutely be an important part of the
interview. It never ceases to amaze me how bad some people are at searching.

~~~
scottyelich
Hell, I've coded in languages that I didn't even know (didn't really even know
what the language was -- I think it was like VB or something) by copying terms
from some sample, reference or other part of the code and putting in the term
or idea I was looking for.

Additionally, just try to look up items on a language that is in (constant?)
flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming
convention changed, parameters changed, etc. All I can say is that thank
goodness Google allows for date ranges with searches. :-)

------
LaserToy
Principal Engineer from huge gaming company here.

White board coding interview are testing only one thing: how well candidate is
prepared for it. And here what is wrong with it: The assumption that candidate
should spend his/her valuable time preparing for someone's assessment is
arrogant. I do understand why Google and Facebook do it (the do other arrogant
things), they assume you want to work for them so much you will study to make
the cut. So, they track bunch of metrics, which makes THEIR life easier. They
have baselines, calibrations, and other things you never have in the real
life. Hilarious part is that they are both risk averse (better to not hire a
good candidate than hire a bad one) and using brood-force approach (they will
interview you endless number of time).

And if you are not prepared - you will most probably fail, unless you are
really good at it or lucky. So, why should I prepare for Google's or someone's
else interview? I have a interesting and very busy job, I just don't have time
for this. I have commitments to my team to work on real products, not on fake
problems from Cracking Google Coding Interview.

Just think how absurd it is?

So, starting from 6 month ago I: 1) Tell recruiters upfront I will not be
spending a minute preparing for their interview process 2) I decline coding on
the whiteboard. High level designs are fine, writing code - no, no exceptions
3) And the most important, I stopped asking candidates to code on the white
board.

The most important skill of the software engineer is (IMO): ability to keep
complex problems in context for long time (not 5 boxes and months), ability to
manipulate them and ability to convince others that you idea is worth
pursuing.

~~~
balls187
> So, why should I prepare for Google's or someone's else interview?

Because you want the job? Everyone is busy, that's a terrible excuse not to
brush up on your interview skills.

By the tone of your post, my sense is that prior to your recent epiphany you
weren't very kind to candidates who you interviewed.

~~~
LaserToy
Do I? There are a lot of great companies, why should I waste time on Google?
Working there is not as fancy as you think.

>> Everyone is busy, that's a terrible excuse not to brush up on your
interview skills. I believe that their approach is arrogant, they just don't
value candidates time.

I have a confession to make, I spent some time at Google. And after I left I
was interviewing people using their approach and I regret it now.

P/S/ When you interview for a company, you actually taking more risk that the
company (talking about folks who are headhunted into interviews). If it
doesn't work out, you will be out searching for a job, you career growth may
be slowed down. And what is the company risk?

~~~
balls187
> Do I? There are a lot of great companies, why should I waste time on Google?
> Working there is not as fancy as you think.

I'm definitely confused. You don't want to waste time preparing for an
interview, but you will waste time interviewing at a company for a job you
don't want?

Yes, there are lots of companies hiring. But in my experience, in preparing
for one software interview, you're preparing for others as well.

I interviewed at Dropbox, Amazon, Valve, and Indeed, within a span of a few
weeks, and the prep work (Cracking the Coding Interview) was applicable to
all.

~~~
mountainofdeath
What LaserToy is saying is that it's not just a little preparation; a few
hours here and there. There are people who turn it into a literal hobby and do
nothing else. If grinding through competitive programming questions is your
idea of fun, then do it. Not everyone has interest in spending 2+ hours a day
for a month to prepare.

~~~
balls187
That point I get, people may not enjoy prepping for an interview.

That's different than asking "Why should I prepare for a job?"

If you want the job, you'll put in the effort to prepare, regardless of your
feelings on the process. That sacrifice (2 hours a day for a month) is minor
in the grand scheme of things. Granted to the OP's point, Google probably
isn't worth it. But that's a value decision each candidate has to make for
themselves.

I'm preparing for my brown belt in Krav Maga. The test is 6 1/2 hour grueling
physical exam that includes a comprehensive test of all the material from the
previous 4 belts. Not only that, we're the first group eligible to test, so
the instructor wants to set the standard with us.

Not everyone wants to put themselves through that hell. But those that do will
put in the effort to be ready come test time.

------
romille
To me, it's not about the code on a whiteboard vs a computer and correctness.

It's about the thought process when breaking down a problem and the ability to
organize and communicate their thoughts. It's also about exploring a problem
space. How carefully does an engineer consider edge cases? What kinds of
things are important to them?

A whiteboard to me is a much simpler and accessible medium through which to
explore a problem vs setting up an environment and having to type code and
dealing with all the minutiae that comes with actual development.

Of course, it isn't the ultimate method of evaluating a candidate but it's
certainly valuable.

~~~
sgslo
If the goal is to test the thought process why not give interviee a self-
directed project then ask them to present a 10 minute talk about it? You get
some code written to verify the engineer can build something, plus you get
confirmation that they can organize their thoughts and effectively communicate
them to another engineer.

Isn't that a more realistic scenario? How often do you give an (employed)
engineer a task then ask them to immediately explain what they'll do to
implement it?

~~~
ep103
Simple, I want them to work on the same topic as other engineers I've
interviewed, so I can benchmark them against each other, and ensure the topic
is close to what we work on, and not just what the candidate happens to know a
lot about.

------
ordinaryperson
Having just been through this process (landed a new job after a 2-month
search), the worst part about whiteboard coding is how humiliated you feel if
you don't get it right or don't know where to start. Is it really necessary to
do that to candidates?

I've been doing this for 15+ years professionally, have a master's in CS and I
struggled to answer many questions. Just stood there blinking like a goldfish.

If companies really wanted to simulate programming work, you'd give me 10-30
minutes to Google the problem because THAT'S HOW IT WORKS IN REAL LIFE. Which
is how it should be; rarely are you solving a new problem, usually other
people have faced it before, it's probably far more efficient to start with a
known working solution and iterate from there.

Look, of course there things you should know. Data structures, algorithm
basics, some complexity theory, etc. But asking me to output numbers in a
matrix in a spiral fashion does not translate into real-world ability.

I find the more important developer skills are people skills and project
management skills. How well do you work with others? How do you resolve
conflicts? What's your methodology for grouping work-- Jira tickets, sprints,
etc?

But almost none of the interviewers seemed to care. They wanted to know what
exotic technology skills I had, not that I could work with project managers
and marketers effectively.

Take-home projects are more time-consuming but the least unfair, whereas
whiteboard coding is the shortest but most unfair.

I blame Google for this curse. I hope the next time I go looking for a job
this process has changed.

~~~
madrox
Asking someone with your amount of experience a coding exercise is silly. You
wouldn't have lasted 15+ years if you didn't know how to code. Spend more time
evaluating the "softer skills," since more experienced engineers have a bigger
impact on culture and process.

~~~
bcassedy
Length of tenure is definitely not a good enough gauge.

I've worked with folks with 15+ years that could technically code but they
took eons to deliver and their solutions were unmaintainable. Some of them
with advanced degrees too.

Small sample size, but the few folks I'm thinking of were such bad hires that
could have been avoided if we had them write some code or put the proper
emphasis on the coding exercise we had them do.

~~~
ordinaryperson
But being a slow worker is going to be revealed during a whiteboard coding
test?

All small programs are maintainable, no interview process will tell you if a
developer can deliver large, complex programs that are clean, modularized and
easy to maintain because there's no time to do something of the requisite
size.

It's true there are experienced devs who suck, but that doesn't mean
whiteboard coding is the process that filters them out.

------
jihoon796
If you must do whiteboard interviews, here's a technique I've used with great
effect:

Have someone else pick a coding problem (that you as the interviewer don't
know beforehand), and work on it from scratch together with the candidate.

Being upfront with the candidate that you don't know the answer yourself puts
the candidate at ease, and you'll be able to better judge the candidate's soft
skills (communication, critical thinking, empathy in case I don't understand
the problem).

~~~
pdxandi
I like this idea. Personally, I struggle with knowing that the interviewer
knows the answer. My wife's in medicine and she and her colleagues call this
process "Guess what I'm thinking?" I prefer to have dialog and come to a
conclusion together, and I feel it gets what you want out of an interview: how
does the candidate think, how deep is their understanding of the technology,
how do they communicate, and would you enjoy working with them.

------
pkteison
I find it weird that the responses seem to draw a distinction between
whiteboards and coderpad. The assumption seems to be that the problem making
the whole thing stressful and unnatural was the communication medium and not
the fact that it's a super time compressed artificial problem with many
unstated considerations and a tremendously outsized influence on the rest of
your life, no pressure, just talk through everything exactly like you never
do.

Most of the problem seems to me fundamentally unaddressable without verifiable
portfolios, but those have their own problems. Even in industries where
portfolios are standard, plagiarism is a thing - how do you get the verifiable
part? I want to hire someone great, not just someone who was on the same team
as someone great.

~~~
jpindar
Even just coding on a computer with the screen cast up on a big monitor or
projector would be a vast improvement over literally writing on a physical
white board.

------
telltruth
I wonder how many of these people are actually active coders which gives them
authority on opinionating on how to interview developers. VPs (especially
Chief XYZs) are typically good sales and marketing guys with engineering
background that often can only be described as hopelessly out of date (or more
politely "has-beens"). They need to keep their heads out of real development
stuff.

I'm also frustrated with how people have developed disdain for anything
whiteboarding. Asking leetcode puzzles in interviews is bad. Asking questions
from CTCI is worse and amateurish. But... asking to whiteboard a problem that
you had to solve on your own job in limited time is good! Interviewing is hard
because crafting such questions in a way that it abstracts away minutia of
transient technologies but retains essential problem solving is hard. This is
exactly why, a right policy for a company is to establish being an interviewer
as a privilege that needs to be earned because not even all brilliant
programmers are good at it and interviewers must take time to craft good
question and show care. When they don't, they turn to leetcode, pick random
question and give whiteboarding a bad name.

And no, whiteboarding is not bad. What is bad is asking to do X using MongoDB
and RectJS because technologies like that are transient. Specific technical
tasks that employees might perform in a given point in time are transient.
Ultimately what matters is ability to learn, process and use that to solve a
given problem. Ofcourse, unless you are company who does nothing but data
driven web forms. In that case, yes, go ahead and ask candidate to do just
that.

------
theptip
The term "whiteboard interview" seems to mostly refer to "solving
algorithmic/coding/puzzle problems on a whiteboard", which I agree is almost
always a waste of time for a software engineering position.

As the article mentions though, the term is a bit vague and is overly broad;
for example if you're doing a system design question, I'd argue that the
whiteboard is the best choice for an interview, since that's how you're most
likely to collaboratively sketch the design of a system in the real world.

I think the problem can be restated at a more general level; does the
interview test the sort of skills that the job requires? Most people here are
correctly pointing out that the skill/knowledge required to write out
pseudocode for quicksort is almost entirely uncorrelated to the skills
involved in most software jobs.

------
anonytrary
Whiteboards, in practice, are never used for writing strict code. They're used
for high-level diagramming and high-level pseudocode.

The only time I've used whiteboards in my job is either when I need to hash
out a solution or approach with my coworkers, because I'm confused or don't
understand the problem, or when I need to understand high-level architecture
for a system. It's a tool for clearing one's thoughts and for getting a team
"on the same page".

If you're hiring someone to code-monkey a bunch of JIRA bugs, then
whiteboarding might not be a relevant test for them. If you are hiring someone
to build out new features efficiently or redesign architecture, then
whiteboarding may be useful for having them describe at a high-level how they
would solve problems. In both cases, writing syntactically flawless solutions
on a whiteboard is a waste of time for both the interviewer and interviewee.

~~~
mountainofdeath
Most selective companies require you to have near correct code in the most
efficient algorithm, clean, correct, concise, with all edge cases in about
30-45 minutes depending on the question. They also seem to love dynamic
programming algorithms and competitive programming tricks (the less common
stuff you glossed over in an advanced algorithms class).

I say this as someone who worked at one and interviewed at others. You really
do need to treat it like an exam.

~~~
anonytrary
Interviews of the sort you describe are like judging a fish by its ability to
climb a tree. Indeed, whiteboards in interviews are used nothing like they are
in real work. I'd hope more companies try and make interviewing closer to an
actual work environment where the candidate can comfortably use their computer
for solving the interview problem, using a whiteboard solely for communicating
concepts and other surface level issues.

------
bhb603
> "Whiteboarding" has become too large of an umbrella term, one that groups
> together everything that's wrong with the interview process.

That general premise is right, we've lumped too much into the term
"whiteboarding", and it's worth unpacking into the different interviewing
practices we may like or dislike. Some things people don't like have nothing
to do with an actual whiteboard (e.g. testing esoteric CS knowledge or
deliberately creating a stressful environments), and some things that involve
a whiteboard IMO are ok (e.g. sketching out a system diagram).

~~~
alkonaut
Yes. The whiteboarding that gets hate is effectively the one where you would
be asked to write a depth first traversal or similar, in some verbose
language, correctly. On a whiteboard.

That is STILL a thing (judging by HN) and it's useless. I don't think anyone
would ever think it's a bad idea to have a whiteboard on hand if a candidate
is asked to describe how they would design some nontrivial system. Being asked
to describe something _without_ a whiteboard in that case, is even harder. The
objection you often get for the latter kind is that it tends to benefit the
extroverted kind that likes to babble and sketch, whereas a candidate who
would prefer ten minutes alone with a pen and paper might not do so well. I
think are some merits to that complaint, but I also know from experience that
being able to babble and sketch is really important.

------
ngngngng
My most recent interview involved a coding assignment, which I topically don't
do, but this one was a very interesting challenge that would make a good blog
post afterwards so I did it. What was surprising is the interview not only
included going over my code from the assignment, but also whiteboard problems
about recursion. I've still never used recursion in my day job. Can
interviewers really not gauge technical ability from my GitHub as well as
chatting about problems and solutions?

~~~
crsv
You have a software engineering job and you never used recursion of any kind?
This strikes me as super odd.

~~~
redisman
I haven't really used it for anything other than super simple things with a
very tightly bound max input. Stack overflow and honestly many recursive
algorithms are quite hard to parse in your head especially once you add some
edge cases and some other entropy.

~~~
dragonwriter
> Stack overflow

Well, yeah, other than tail recursion with tail call optimization, stack
consumption, if not stack overflow, is always an issue.

> and honestly many recursive algorithms are quite hard to parse in your head
> especially once you add some edge cases and some other entropy.

I find lot of things are easier to conceptualize recursively than iteratively,
though _parsing_ really depends a lot of the language.

------
raz32dust
Whiteboard is GREAT for communicating design or technical ideas (e.g, what is
consistent hashing, can you show how you'd merge N sorted lists
schematically?). And these skills are super important in both big companies
and startups. And we should definitely test candidates in these areas using
whiteboards.

Making engineers write code on whiteboard is just comical. If we weren't so
used to it, we'd probably have laughed at the idea. In 2018, any company still
using whiteboards to write anything more than pseudocode is just playing it
too safe or being really lazy in changing their process. Just give them a
laptop and have them use coderpad/skype interviews or any of the plethora of
collaborative code editors out there. Or even, dare I say, an IDE. You can
still have the whiteboard in the room to discuss the idea. But write the code
on a laptop with internet access.

------
dqpb
I think most people that are opposed to coding interviews feel that way
because they don't feel confident in their ability to do those interviews
well, whereas they do feel confident in their ability to "get work done".

Here's the thing though. Let's say you're the one giving the interview to two
people who claim to be able to get shit done. One is able to code up a
solution quickly and the other struggles, producing less, or producing
something that's flawed. Sure, that second person might actually be productive
under the right circumstances, but that doesn't matter because the first
person already proved they can code.

That's the whole point of interviews, getting high signal in a short period of
time. If you think coding interviews don't provide high signal than propose
something better that costs the same amount of time.

~~~
Retra
Your resume, Github account, demonstration of previous projects, ability to
discuss problems you've solved, references from previous coworkers &
instructors...

The whiteboard is not providing "high signal". Everything else is. The
whiteboard is providing low signal, and taking quite a bit longer to do it.

------
fareesh
I generally ask candidates what they did last week at their existing job, and
then ask questions about how they solved specific aspects of that particular
job.

If the person says "we built real-time tracking for our in-house vehicle
fleet", I will just probe further and further about what role they played and
how they went about the specific implementation details.

If there is any kind of secrecy surrounding their work, I will simply offer
them insight into what they'll be tasked with during their first week and ask
questions in a similar manner.

I'm not sure what advantage any other approaches have - I am hiring to fill a
particular position. It's quite likely that the candidate will be in a similar
position, so either I ask them about their current work and how they went
about it, how they intend to accomplish the work assigned to them when they
work with me.

------
devy
Serious question, if whiteboard interview aren't the best or helpful at all,
what are the successful/useful alternatives for engineering interviews?

~~~
optimuspaul
The best I have come up with if you are requiring them to write actual code is
to give them a problem to solve for with code prior to interviewing. Have them
bring that code along and then have them explain the code and why they did
things the way they did. It is not 100% verifiable that they wrote the code,
but being able to talk to why things were done the way they were tends to be
good enough. I have also found that understanding how people approach life and
problems in general are more telling of how good they will be than actually
evaluating their coding skills. Monitoring coding exercises will weed out many
good candidates as well as the poor ones in my experience.

~~~
ordinaryperson
Exactly.

During my recent job search I was asked many questions I didn't know the
secret algorithm to, but if those companies had given me the problem ahead of
time and allowed me to research it -- just like what happens in real life -- I
could have coded solutions to all of them.

And if you're worried about people just plagiarizing existing solutions, have
them talk through it, as you say. Should be fairly clear if they understand
each line or not.

------
liquidise
Whiteboard coding measures penmanship while nervous.

I have some firmly held opinions [1] on this topic. Interviews are too much of
an "art" for how important it is that their results be repeatable. Keep them
on topic as much as possible. Making a coder perform circus acts on a
whiteboard they will never be asked to do otherwise is simply measuring for
skills you don't need.

1\. [https://blog.benroux.me/whiteboard-coding-measures-
penmanshi...](https://blog.benroux.me/whiteboard-coding-measures-penmanship-
while-nervous/)

------
renegadesensei
They're fine but they need to be understood properly. Whiteboard interviews
don't really capture how well someone codes. They are better at capturing
thought process, high level understanding, system architecting ability, and a
candidate's communication skills.

If you want to see how well someone codes, look at their code. Or ask them to
write something for you. Don't do a whiteboard interview and think it is the
end all be all. Take it as a data point.

~~~
ordinaryperson
> They are better at capturing thought process, high level understanding,
> system architecting ability, and a candidate's communication skills.

If that were the case, ask me about a past problem and my solution and to
defend it, not the proper way to invert a b-tree.

------
simpixelated
For anyone that wants to work for a company that DOES NOT do white-boarding
during interviews, here's a solid list: [https://github.com/poteto/hiring-
without-whiteboards](https://github.com/poteto/hiring-without-whiteboards)

------
11thEarlOfMar
Nay.

We have a round of interviews and then send the candidate home with a choice
of 5 coding tasks. Intention is to spend no more than 2 hours. Then they
return and hold a code review in front of the team and explain what they've
written. That way, they code at their own pace and in a comfortable space
where they can focus, much like the way they would actually work. Then they've
got it all right in front of them for discussion.

The review then weeds out people who don't really understand what they've
written, possibly because they borrowed it from somewhere or asked a shill to
write it for them.

We've had a range of submissions, from the casual-careless-broken code to
extremely complete to elegance like we've never seen before. It works well.

------
usrusr
Random fun idea: pair whiteboarding, have one of the reviewers start
improvising a solution (or put on a show of not having done it dozens of times
before) and see how the candidate will contribute.

If the problem is not one of the standard ones (that will be perfectly
memorized by desperate candidates, while rightfully confident ones may
struggle), it will demonstrate understanding, not the irrelevant ability to
sequentially write out code in an unfamiliar medium. After all, you probably
don't want to hire those who have already been rejected so often that they can
code on a whiteboard as if they did it all day.

------
oh-kumudo
Yes? It designs to filter people based on certain criteria. Nowadays, you just
can't get a job by merely talking, the market is too hot, too many people want
to get in.

I don't think design interview alone is that useful either. Someone without
actual experience designing stuff could still fake it by reading other
people's past solutions and answers, there are templates on the internet.

Nothing is inherently bad just because it fails you. Everyone saying Google's
process is broken, blahblah, doesn't change the fact Google employees are hot
AF on the job market.

~~~
jpindar
>Nowadays, you just can't get a job by merely talking

You can if you're willing to work for a smaller, non-famous company.

------
jakeinspace
I'm an almost-graduated computer engineering student. I had a relatively
pleasant interview last week with a whiteboard component which I thought was
fair. The interviewer asked for a Fibonacci function, an easy problem that
still allowed me to show that I understood some more advanced concepts. I gave
a basic recursive solution, was asked to critique it, explained how it was
inefficient in time and space, and would blow up the stack (without tail call
optimization). Then I thought I'd mention dynamic programming as a possible
solution to the time complexity, but one that would still cost a ton of stack
space. Finally, I gave the iterative solution, and explained how it was more
efficient, and how you could use it to pre-compute a lookup table.

The interviewer propmpted me along the way, it felt like a friendly
conversation. The fact that it was an easy problem prevented me from stressing
out, but I still felt like I was able to demonstrate some academic ideas.

I was always pretty decent at standardized tests as a kid, and this argument
over whiteboarding reminds me a bit of that. I don't think it's useful for
gauging general software engineering skills, but it might have some value for
evaluating communication. It also feels like the sort of thing that software
engineers with a strong academic background tend to enjoy more than those with
more practical/industry experience, but that's just anecdotal.

------
expertentipp
Honestly I’m not afraid of whiteboards as earlier in the career. The
interviever is whether some fresh graduate smartass trained in a narrow domain
and it’s easy to route the discussion out of their comfort zone, or someone
with particular problem - well, I’m not able to pull out immediately answers
to the world problems and if this is the case I’ll just admit it. In the worse
case I’ll not get hired - I hadn’t got hired too many times in my life to
care.

------
pan69
As with everything, it depends.

To me, whiteboard interviewing makes sense when hiring for a role that leans
toward a comp-sci background. People who do well in these roles typically have
a brain that works in a certain way.

The roles that lean away from a comp-sci background are usually the type of
developers who don't do well with whiteboard interviewing techniques.

What too often happens is that a hiring engineer doesn't interview within the
context of the role they are hiring for.

~~~
ordinaryperson
> People who do well in these roles typically have a brain that works in a
> certain way.

You know this how? Intuition?

People have all different kinds of backgrounds and brains.

------
andrei_says_
I’d be curious, are interviewers running whiteboard interviews willing to do
one, conducted by a colleague, in front of their team?

Does this practice exist anywhere?

It would be interesting to do this maybe once a year? And put $100-500 toward
getting a pass or non-pass(money gets donated to interviewer-selected
charity), just to throw in some money in the game?

And I mean an interview based on non-trivial CS problems, not brainstorming /
code ideation which we do often.

------
anonytrary
I'd propose a supplement for interviewing. If your company has at least one
open-source repository:

1\. Have a senior engineer chat with the candidate for an hour about a few
bugs/features in the repository, and how the candidate would solve them.

2\. If the candidate is promising, give the candidate a week or so to fix the
bugs or implement the features.

I think this would be a more relevant test than just giving them context-less
problems to solve on a whiteboard.

~~~
mmt
Make it a paid project, and it at least partially addresses the sibling
comment's (valid, IMO) complaint that it filters out candidates that are
otherwise in high demand.

It would also provide a significant signal regarding valuing the candidate's
time and effort [1], which would comply with the suggestion of another comment
elsewhere in the thread.

[1] As well as the additional signal of putting money, rather than just "free"
candidate labor into open source.

~~~
anonytrary
Companies already pay thousands of dollars (per candidate) to fly out,
accommodate and feed candidates for on-sites, so this doesn't seem
unreasonable. Similarly, phone-screens and other filters would be done before
a paid task is given.

------
curtis
Many people believe that it is completely unreasonable to ask an interviewee
to write code on a whiteboard at all. I disagree with such an absolute
position. I do think it _can_ be a reasonable thing to do, _but only if you
are asking the interviewee to code something really simple._

When I say _simple_ , I mean really simple, like FizzBuzz simple.

There are interesting questions you can ask that are really simple which are
not FizzBuzz. I've used the Fisher-Yates shuffle algorithm and more recently
Selection Sort. I should stress in both of these cases that I carefully
explained the algorithm before asking the interviewee to code it up. Even
though these algorithms are quite simple, I do not expect the interviewee to
have memorized them.

I do expect someone who is a professional software engineer to _understand_
the algorithms after a decent explanation and then write code which will
implement them.

I also don't necessarily expect the interviewee to get the code exactly right.
I just expect them to demonstrate that they could write correct code given
enough time and access to an actual computer to test the code on.

~~~
BinaryIdiot
If you're looking for them to do something _really simple_, like FizzBuzz,
then you're doing it wrong already. This is something that could have taken
place over a technical phone screening.

Once they hit the on site interview it should be more about how they can work
together with a team, how they would design systems, what they would do if
they needed help, etc.

Coding up FizzBuzz on-site is a waste of everyone's time.

~~~
curtis
We're a small startup, and we don't have a really structured process. Also I
have been the only person asking a detailed coding question (in consultation
with my boss). Everybody else on the team has been responsible for those other
questions.

I should also add that I personally prefer to do coding questions in person on
a whiteboard, rather than doing them during a phone screen with some sort of
collaboration software.

My technique of explaining the algorithm before asking the interviewee to
implement it works way better with both people in front of a whiteboard.

I'm not saying everybody should do it this way. I'm just saying that this is
my current approach and it seems like it's working OK.

~~~
BinaryIdiot
I mean if it works for you then great but I've seen that back fire far too
many times where I had to interview an incoming candidate who didn't do any
coding over collaboration software and then couldn't do simple FizzBuzz.
Basically wastes their time traveling and interviewing and my time when a
quick check just to make sure they can do a few, quick basic things over the
phone can save so much time.

While I dislike the way most large tech companies handle their interview
process this one I don't mind as much.

------
Will_Parker
Is there any engineer who you'd regret not hiring, who is unable to code
FizzBuzz in real time in front of an audience? I'm skeptical.

~~~
jonathankoren
I've seen a respected engineer that I worked with for years, be told by an
outsider that he was incompetent because he couldn't fizzbuzz an interview.
Yet, they had no problem acquiring the project he designed and wrote.

So yeah.

~~~
dvirsky
Why couldn't he do fizzbuzz?

~~~
anonytrary
"Why couldn't he do fizzbuzz with someone else watching his every move while
he wrote on a blackboard with no interpreter to test his solution or catch his
mistakes?" seems like the better question.

~~~
vultour
You're assuming quite a lot here. Was he not able to write flawless code
without syntax errors, or did he struggle with the core idea of FizzBuzz?

------
balls187
How do engineers approach solving a problem?

Whiteboard coding does a good job at assessing that, regardless of the
candidates ability to actually solve the problem (for all the reasons why
whiteboard coding sucks).

Do you analyze the problem?

Write test cases first?

Write a mini spec?

Gather Requirements?

Ask Questions?

Jump into code?

Google?

Verbalize the problems you encounter?

In that respect, engineering coding interviews work well. But too often, they
are essentially a binary Yes/No: Candidate solved the problem the way I want
them to solve it.

------
ww520
Whiteboard as a communication tool in interviews is great. Sometime it's
easier to write things down, draw diagrams, and list technical points than
just talking about it. Writing it on the board provides an outline to talk
about stuffs.

Whiteboard as writing programming pseudo code or steps are fine. Just don't be
a human compiler and demand perfect syntax.

------
castlegloom
It seems like there are two things at play - whiteboarding interviews vs.
using whiteboards in your day-to-day job.

If the test is to see how well a person works in a whiteboarding interview to
solve a problem, then it should be a simulation of collaboration, while trying
to avoid the Clever Hans effect.

Otherwise your DP whiteboarding problems are worthless.

------
denzil_correa
In general, an interview is to understand what a candidate brings to the
table. Therefore, one of the best ways to assess "glass half full" is to talk
about their past work. The interviewer is a subject matter expert who can
definitely ask pertinent questions about the candidate's work. In many cases,
more so for scientific positions - the candidate's work is publicly available.

Currently, many interviewers go for - as I like to call it -"trivia
questions". Personally, it just doesn't seem appropriate because "Everything
may be obvious, once you know the answer". In some such interviews, I've asked
my own set of trivia questions to the interviewers. The interviewers weren't
pleased as they couldn't answer some questions for which I knew the answers
beforehand.

~~~
haeffin
Unfortunately, some companies' HR departments actively encourage "trivia
questions", because they ask interviewers to ask every candidate the same
questions so that a "fair" comparison between candidates.

~~~
KhanMahGretsch
I think you've touched on a crucial point here about making the comparison
"fair". In my view, I find the "trivia questions" approach to be an abdication
of responsibility for the difficult, nebulous task of assessing a candidate's
abilities. It gives you an objective measure by which to compare candidates...
even though the measure itself is usually arbitrary and irrelevant.

------
tzs
A couple of comments have mentioned LeetCode. While reading those comments I
had an odd idea on a different way to use LeetCode when interviewing. The
usual way would be to get problems from them and spring those on the candidate
to solve on a whiteboard or on a computer. Numerous people have raised
objections to that kind of interview.

Instead, how about sitting down in front of a computer with the candidate,
going to an interesting problem on the LeetCode site, and reading the problem
statement with the candidate. Make sure you both agree on what the problem is
asking for.

Then, instead of having the candidate solve the problem, go to the discussion
page for the problem, and start reading the posts with the candidate. These
will include posts from people who are asking for help understanding the
question, and from people who are showing off their solutions.

Pick a few where the poster is asking for help understanding, and ask the
candidate how they would clarify things for the confused poster.

Pick a few where the poster is posting their solution, and ask the candidate
to do in informal oral code review along with you. Let the candidate take the
lead, just providing nudges if necessary. For ones where the review finds
serious bugs, talk about how to make test cases to demonstrate the bugs.

From what I've seen on LeetCode problem discussions there will be a lot of
posted solutions that have edge cases that fail, or fail to meet time or space
requirements that were given, or leave out major cases, or make implicit
assumptions about the input that if violated invalidate their sultion. There
should be no problem finding plenty of posts with plenty of things to bring up
in review to discuss with the candidate.

This seems to me that it would not be overly stressful on the candidate (way
less stressful than writing code under a short deadline), it is exercising
skills that working programmers actually use, and it would let you do some
work with the candidate to get some idea of how they get along with others
when working.

------
markatkinson
I recently had a coding interview and it was a disaster. The annoying thing is
it was actually a super simple question and I had done a lot of preparation,
and had solved a similar issue in my actual job just by chance a couple weeks
before. So it started out great.

But instead of acing it an issue cropped up in the coding pad which I had to
try and debug, which threw me off guard. The interviewers had muted their mic
and were chatting away and my nerves just crumbled and I ended up profusely
sweating into my eyes, I literally had sweat going into my eyeballs. I just
turned into a bit of a mess, which is strange for me as I'm normally quite
confident.

I think if the interviewers were a bit more involved it may have gone better.
But I ended up just not finishing in time feeling like I had wasted everyone's
time.

------
DrBazza
Yes to whiteboards if they're used correctly.

If the candidate can't explain or solve something simply on a whiteboard, they
probably don't understand the problem or domain.

That's not to say that the interviewer might not be a great interviewer in the
first place though.

Quote: "Feynman was a truly great teacher. He prided himself on being able to
devise ways to explain even the most profound ideas to beginning students.
Once, I said to him, “Dick, explain to me, so that I can understand it, why
spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience
perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came
back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the
freshman level. That means we don’t really understand it.”"

------
dvdhnt
Yeah, no. At least, not to test the technical proficiency of a potential team
member.

Instead, have a conversation about how to solve a well defined problem. Use
the whiteboard to record potential solutions in high level terms, or if the
candidate chooses, to note key concepts or concerns.

Your interview environment should be a "staging" environment for your day to
day operation. The interview should gauge how the candidate might affect your
development process.

Once the interview ends, snap a picture of it. When you're debating candidates
and try to remember your impression of them and how they contributed. Consider
the sum of the input they verbalized and the input they wrote. That should
give you a good idea of what they'll offer - well, along with your impression
of them to that point.

------
arcticbull
In my experience conducting engineering interviews (about 300ish so far) I
much, much prefer pair programming interviews in front of a computer with an
IDE and access to the internet and standard resources. This most closely
resembles how we work together and engineers and gives candidates the best
chance to show off their skills. Whiteboarding code is something people almost
never do in their professional careers, and as such, you focus on all the
wrong things (is that the name of that library method? is that where that
semicolon goes? is that best practice?). It's neither fair nor representative.

Of course I have no problem testing architecture and communication ability in
front of a whiteboard, as this is much closer to how these things are done in
the workplace.

------
z3t4
I think in images, and always visualize the problem, so I would love doing it
on a white-board, I actually find it easier then writing the code itself, and
I find it very hard to describe the problem in words. While others think in
code, and yet other people think in words. So in order to not dismiss a good
candidate, explore how they think about problems. Can they describe it with
words ? Can they describe it with code ? Or maybe they can only describe it in
pictures !? There are also other ways of thinking. Some people think in
shapes, then solves the problem like a puzzle making the shapes fit together.
These guys/girls might be on savant level and would have a very hard time
passing any traditional interview.

------
gregrata
So I've been frustrated by this type of interview for years (on both sides,
but the last 10 years on the hiring side). I don't think it's great finding
people that are good at writing software (as it's a LOT more than a single
algorithm and more than just coding).

I wrote a book it - along with what I've been using the last few years, that
actually seems to work - or work at least a bit better. In the end, I don't
think you really know unless you work with someone.

[https://www.amazon.com/dp/B07FJ6N8P1](https://www.amazon.com/dp/B07FJ6N8P1)

It's my first attempt at a book (small as it may be!) - I'd really appreciate
some feedback (and it's free right now)

-Greg

------
unrealchild
We offer a whiteboard for the onsite if it will help a candidate communicate
comfortably. Narrative is totally fine, gesticulations, metaphors,
interpretive dance, whatever means of communication works to get the point
across. We send out a small HW assignment before an on-site, after a phone
screen. Not all candidates enjoy it, some expect an algorithm driven
whiteboard experience. Our process delivers for us, and we tend to naturally
attract a good culture fit as a byproduct.

In practice we do end up at a board day to day explaining ideas and so on, and
everyone seems more than comfortable (with the exception of handwriting
insecurity).

------
keithnoizu
I always do horribly on these. I also don't have a degree in computer science
so although I can setup a binary search tree, etc. well enough if work demands
it I don't have the muscle memory of working with them intensively over and
over again to spin out solutions to interview questions.

Once in the workplace however I usually get promoted up pretty quickly. I'm
pretty handy with generics and meta programming along with architecture and
design patterns, meaning I can turn out more complex systems in much less time
than most of my coworkers. But that crap never comes up in the
google/microsoft interviews of the world.

~~~
adrianmonk
IMHO, people with/without CS degrees should be evaluated by different
standards/methods.

If you do have a CS degree, then I expect you to be able to show decent
competency with that material because you were sitting in all those classes
for all those years. If you didn't learn anything, it makes me question
whether you apply yourself to what you do or just coast through stuff and are
going to coast through at this job too. Since we have the shared experience of
a CS degree, if I understand what you got out of it, I think it tells me
something about your attitude and approach to your work.

If you don't have a CS degree, then I am going to focus more on skills
required for the job role itself. If being strong on algorithms is really
necessary for the job, then I'll need to cover that. For any job, though, I'll
need to convince myself you have a certain base level of competency so that,
for example, you know that a linear search of a billion items is bad.

------
madrox
I've always been in the camp of not doing coding interviews...whiteboard or
otherwise. Overall, that's worked well when hiring engineers with 3-4 years of
experience or more.

Less experienced engineers are very difficult to assess without some kind of
coding exercise. All the hires I've made that I'd characterize as mistakes are
of junior engineers that I didn't do a coding exercise with and interviewed
well, but didn't bring that interview polish to the job. Since instituting
whiteboard exercises for junior positions, our success rate has been higher
(no pun intended).

------
halis
If you're going to interview someone that is going to write code that a
computer runs, then make them write code and run it on a computer IN THE
FUCKING INTERVIEW.

Silicon Valley is retarded.

------
a-dub
Whiteboard interviews would be fine if they weren't taken so damn literally.
Writing code on the board is dumb.

Spitballing solutions to a problem collaboratively and with access to
reference resources (a nice little programmer's bookshelf in the room)
followed by actually coding a little bit up seems that it would be way less
stressful and way more likely to give you a sense as to what someone is
capable of and what they're like to work with.

------
Madmallard
If you can solve arbitrarily hard problems while on the spot you must be a
stellar candidate from a problem solving perspective. If you can effectively
articulate your thought process as well you probably have great communication
skills and can handle technical discussion and group problem solving for
harder problems. It's gonna weed out a ton of people that can do the job but
the guys that rock it will probably be valuable assets.

------
beders
I've been on both sides of this. Whiteboard interviews are good for a couple
of things: Can the candidate explain a problem on a whiteboard? Is his hand-
writing legible?

It's not sufficient to decide if someone can code. You want some actual code
written by that person.

And you don't need everyone on your team being able to explain things well on
a whiteboard. Just try to figure out how they are thinking and how they are
approaching a problem.

------
relate
I've done whiteboard only interviews, as well as shared doc/coderpad only, and
I find both limiting. When thinking about the problem, it's great to have a
whiteboard to sketch examples etc, but writing code is much easier with a text
editor.

Recently I interviewed at Google, and they had no problem fulfilling my
request to do both: sketch the solution approach on whiteboard and then write
the code with a laptop.

------
swyx
great article! it would have been nice to have a comparison of yays vs nays,
like for example 67% of engineers say nay, whereas 50% of companies on key
values do have some sort of whiteboarding in their process. with the caveat of
course that the kind of companies that talk to you (keyvalues) are probably
more progressive anyway so there is selection bias.

but it very much does seem like whiteboarding is on its way out.

------
lambdasquirrel
> _What’s great about a white boarding session is that it is a blank piece of
> canvas, where the interviewee can effectively think out loud, collaborate,
> draw diagrams and also brainstorm with the interviewer._

Is the typical engineer conducting an interview good at contextual inquiry? At
holding space for people to think out loud? Lets not kid ourselves here. The
only people we’re harming are each other.

------
ggggtez
>Software engineers hate whiteboard interviews. How do I know? We continually
tell complete strangers just how much we hate them.

And yet, whiteboard interviews are probably 3rd on the list of flamewar topics
behind vim, and whitespacing. So there is clearly some people who don't hate
them.

I count myself in the camp of people who don't relish the world before
fizzbuzz.

------
deskamess
If someone gets hired, and on the job in the next year, they do not
implement/discuss the interview questions in any non-interview situations,
then drop those interview questions. When a candidate fails to answer a
question/task, ask the co-worker who asked the question/task to complete it
(and be just as strict with them).

------
dvirsky
Programming without being able to insert lines is not indicative of real
programming. To me that's the bottom line.

------
dm7
whiteboarding is essential when hiring for roles where development environment
is not productive. there are still huge systems which take 5 minutes to link
on fastest machine, or embedded, real-time and distributed systems where it
takes so much time to debug that one's daily productivity would be close to
zero unless he writes code which would be mostly correct before first run.

developing under such constraints is radically different from environments
with high iteration velocity - i.e. browser or scripting.

that said, in many modern environments whiteboarding is completely irrelevant,
as modern application level programmer productivity is often ability to do
plumbing-and wiring- work between many components and quickly assess why
something is going wrong, rather then creating a highly performant or memory-
efficient algorithm implementation.

------
PopeDotNinja
I'll stop short of saying whiteboard interviews, with or without coding, are
suboptimal. I will say that any interview question which attempt to see how I
think is suboptimal. How I think when on the spot does not reflect how I think
on the job.

Speaking for myself, I like pair programming interviews.

~~~
redisman
I like pair programming interviews too, the only thing is that there's still
some murky-area between interviews of how much should you lean on your pair
and how much should you prove independent problem solving.

------
solidist
The meta of how on whiteboard interviews.

[https://medium.freecodecamp.org/how-to-organize-your-
thought...](https://medium.freecodecamp.org/how-to-organize-your-thoughts-on-
the-whiteboard-and-crush-your-technical-interview-b668de4e6941)

Just embrace it. It will be okay.

------
blubb-fish
whiteboard tests are always going to produce fuzzy red and white flags. those
will come handy later when it gets to assessing the applicant based on
sympathy and arbitrary objective arguments are required to back whatever the
interviewer wants to conclude.

------
jjbinks
I've done close to 500 intermediate and senior level engineer interviews for
one of the top 3 tech companies. For a time we offered candidates a laptop to
code on during their interviews. To my surprise over 70% preferred the
whiteboard. Go figure.

------
AgentOrange1234
I’ve interviewed a lot of folks, and bitter experience had taught me to always
ask at least a couple of whiteboard problems. I’ve often been completely
shocked that someone I thought seemed promising was unable to think through
basic problems.

------
glitchc
No in general.

If yes, the problem should be simple and relevant, and the session highly
interactive. The assessment should be about (a) How interested the candidate
is in the problem (b) How receptive they are to feedback.

------
rafiki6
I feel like this topic comes up on HN every six months and we all lament the
broken state of technical interviewing, and the ardent supporters of all the
different styles come in and push their position based on success perceived
from anecdotal evidence. I have a hypothesis that hiring a good candidate is
mostly luck.

When we view the hiring process in the context of what it actually is, a sales
relationship, we realize that the customer (i.e. the employer), is ideally
looking to buy services and time from the business (i.e. the
employee/contractor). Viewed in this context, we quickly realize that many
different things become part of the equation. Think about hiring a contractor
for your home. If you happen to understand the job they do, you might be able
to assess a the potential contractors previous work, quote and reputation
effectively. Most people can't because they generally don't understand what it
might take to do a job and have no experience in executing it even if they do.
So you either heavily rely on recommendations from others, or go for a lower
or higher priced contractor based on your perceived value (cheaper job, w/e
the results vs more expensive job and risk mitigation) and hope for the best.

Considering most software development doesn't actually happen at "tech"
companies, the reality is most companies are like most people and likely can't
properly assess talent no matter what. They essentially get lucky if they get
a good candidate or unlucky if they don't. That would lead us to think that
maybe the "tech" companies are able to do a better job of it. In essence they
do, but not because of their methods. I'd say it's a form of selection bias.

Google became successful and happened to be run by generally smart people
technically capable people. As such they were able to attract generally smart
technically capable people to work for Google. I'd venture a guess that 90% of
people who make it to the live interview stage at Google would be qualified to
work there, but since Google has it's pick of the litter they need to create a
filtering system somehow. They happened to make it the "whiteboard" interview
and similar high achieving Peer companies all tend to do the same thing. It
became a thing, and as such all non-high achieving companies followed suit so
they can behave like the high-achieving companies. The filter a company like
Google applies is only necessary because they have too many candidates. Most
companies aren't in a position to apply that filter if they really want
talent. So really, they need to get lucky enough to get those who don't
interview well with the "tech" company method of interviewing and hope they
get some of those prime candidates.

I'm pretty sure the tech talent pool, as with all things in life, follows a
Gaussian distribution. If you interview enough people you're bound to find
some decent ones, even if they don't actually interview all that well.

~~~
redisman
I think Google is seeing a positive signal on their hiring process because a)
they get a high percentage of the best programmers applying there at some
point in their lives, and b) they run de-facto IQ tests on the onsites to pick
the cream of the crop from that pool. It might not be the "best" raw
programmers (that's impossible to define anyway) but being able to perform
well on the algorithm tests means the people in general are highly
intelligent.

~~~
rafiki6
Exactly. In general, if you do well it means you're probably pretty smart
(whether you've memorized or figured it out on the spot). If you don't do
well, it just means it's not your type of test most likely. I'd say this
creates an opportunity for non-Google like companies to moneyball their teams
and get some high quality talent at a discount because they suck at passing
the Google filter. If these companies were smart, and considering how much
luck is involved in the process anyway, they should look for a different set
of criteria to evaluate a candidate on.

------
wolco
I may be an outliner but I prefer them. Mixing presenting with randomly
writing things is better than talking for an hour. Makes me less nervous doing
two things at once.

------
serp3ntine
Yea* or nay, not "yay" or nay. Damn millennials...

------
jrs95
This is one of those things that even if it can be done correctly in theory,
it’s often so bad in practice that it’s probably best to just not do it at
all.

------
onemoresoop
IMO whiteboard interviews are disadvantageous to shy people. However, that
aside, generally in meetings whiteboard could have some benefits if not abused

------
nofunsir
The Chief engineer at my current place of employment said, and I quote
verbatim: "I get a sort of sick pleasure from watching them squirm."

------
bitshepherd
As a senior-level self-taught, I redacted this post because of my views on
whiteboard coding. Downvotes are not cool.

------
nnd
Whiteboarding or not, what are some good resources to prepare for a coding
interview that worked for you?

------
sebringj
Waterboarding and whiteboarding are phonetically similar as well.

------
GenerocUsername
I actually really like whiteboarding problems and it is a common and effective
real-world problem solving skill.

I still only do OK at whiteboarding in interviews.

------
dionian
whiteboard is more useful for design than code, i give them a computer to code
on

------
ben509
There are three goals in interviewing: for the interviewer to gather enough
evidence to prove that the candidate is going to succeed in the role, evidence
that they will grow in the long term, and to sell the candidate on the
position.

A whiteboard interview isn't a good growth indicator, but it's great at
leveling a candidate. Moreover, it signals to a candidate that their peers
will be at a similar level.

So I'd vote yay. If you pay attention, you can determine someone's proficiency
at coding on the whiteboard in about 15 minutes. This is particularly
important when you have people who are changing careers or junior or otherwise
don't fit the mold.

I'm honestly shocked at the arguments against whiteboarding as many of them
seem entirely reactionary.

"But I'm never going to work that way."

Didn't we all do the better part of two decades of formal schooling? We test
people like that for a reason: you can carefully focus on the specific markers
of mastery of a subject.

I understand why people make this argument: it's a reaction to some of the
weird puzzles companies used to ask. But it's never substantiated that this
will help the interviewer and candidate make a better decision, so it has the
same problem the puzzles did.

"But at work I have Google and StackOverflow."

This is a good point, the questions you ask in a whiteboard question should be
based on the fundamentals rather than trivia. But it's a terrible point
because it accepts that the interview is just a ritual you go through and this
argument is that we should make it fair.

Whether a candidate knows "the answer" is not the point, it's more that
they're able to talk about what's going on, have good instincts, etc. If
you're an experienced engineer, you've seen lots of people write code, you
know what looks like "junior" or "senior" and "guy who thinks anyone can just
pick up coding."

"But if I work on a computer I can compile and see the edge cases."

Are you interviewing the candidate or the compiler? Again, this is the
ritualistic view of interviewing.

"But at work I have plenty of time to work on things."

Everyone has this problem, so everyone is less able to perform, and the
interviewer can simply adjust expectations.

"All of these interviewing "tools" (or tricks) attempt to be time/cost
efficient proxies for doing the damn job..."

That's very much the ritualistic view. Other industries have had notions of
apprenticeships and so forth for thousands of years, and our problem is that
we view recruiting, professional development, etc. as things someone else
does, rather than something we take ownership of. Interviewing is a critical
business function, it can produce value and thus is not a waste of time. If
you treat it as a useless ritual, though, it will be.

------
megaman22
Nay. I do not understand the obsession with whiteboards. I've had coworkers
that went gaga when they discovered that whiteboard paint was a thing, and
they could cover their office in whiteboard surface. Doodles and doodles and
doodles all over the place, but not very much working code ever makes its way
into production from those offices. Lots and lots of movement and noise and
grandiose planning, signifying nothing, too often.

Lock me in a dark closet under the stairs with just the glow from a couple
LCDs and throw pizza and requirements documents through the slot, like you're
feeding the Rancor. /s

------
h4b4n3r0
Nay, unless the candidate wants the whiteboard. Even Google doesn't mandate
whiteboard anymore: you can write your code on the provided Chromebook. Some
people choose whiteboard, though, for reasons unknown. I think whiteboard (or
a sheet of paper) is reasonable for what it gets used for IRL: for sketching
out what you're going to do, by drawing or writing very high level
description, but it sucks for everything else.

~~~
miah_
I did a interview with Google last summer. They didn't use a whiteboard, but
instead had me code in a shared GoogleDoc. Pretty similar issue, limited time,
somebody staring over your shoulder, not your usual development environment.
Even more frustrating when you _know_ they have a web-based IDE for internal
software development but make you write code in a GoogleDoc.

~~~
cableshaft
Was that an on-site interview or a technical interview over the phone? I did
an interview at Google about 7 years ago and that sounds like the Technical
Interview.

When they brought me on-site after that, I interviewed face to face with 5 or
6 people in a row (except for a lunch break), and every one of them asked me a
two or three questions and then switched to tricky whiteboard problems.

I remember one was 'write a function that draws a 2D skyline from a bunch of
3D buildings', which I got totally stuck on because there's so many possible
configurations of heights and widths and how they overlap that complicates it,
so I didn't really know how to properly solve it.

I didn't get the job. I thought the experience was interesting at the time,
and basically treated it as a free tour of Google and a chance to eat In and
Out burger again, but I don't want to go through that grueling exercise again
(or spend a ridiculous amount of time prepping for it... as it was I spent a
solid two weeks studying for it the first time around), so I've said no to
Google recruiters every time they've gotten in touch with me since.

I might have given it one more shot, though, if I were willing to move to
Silicon Valley at this point in my life, but I just bought a pretty decent
house and I'm not really wanting to give that up to take out a mortgage five
times what I have here just to live in a smaller house in the Valley and be
able to say I worked at Google.

------
debt
I love these kinds of post. It's like saying:

"Highways: Yay or nay?"

"Food: Yay or nay?"

"Air: Yay or nay?"

Hate on whiteboard interviews all you want, but that attitude is going to put
you a massive disadvantage in the current rigmarole of software engineering
interviews. It's not a thing 99% have any interviewees have control over. Nor
is there a way to tell the interviewer: Hey, I prefer not to do whiteboard
interviews. It doesn't work like that.

