
A listing of companies that don't do whiteboard job interviews - ohjeez
https://github.com/poteto/hiring-without-whiteboards
======
jboy55
Its interesting how many of these companies have 'take home' challenges or
projects. Even though the companies may say, "This should only take an hour",
99% of the time, it occupies my entire night/weekend, if not in coding but in
thought. There's always something more you could do. Its presented as an
objective test, but its very subjective, just as much as the whiteboard test.

With the whiteboard test, as a candidate, I know that when my hour is over,
its done. Plus, I can get feedback during my whiteboard session to know if I'm
on the right track, I can ask questions and get guidance on where to
concentrate my efforts. With take home projects, I've woken up in the middle
of the night and thought, "Wait, I know this is a full stack position, and
they said that the UX just needs to be functional, but maybe my CSS knowledge
is too old, and there's a better/newer way of doing the styles. I should
really spend all night researching this, wait, BOM?! I should convert over to
that, I don't want the front eng engineer reviewing this code and saying, OMG,
this is so old, NOHIRE!"

EDIT:

Also, take home challenges are probably very discriminatory towards older
candidates with families. So maybe just as subtle way of age discrimination?

~~~
hn_throwaway_99
> Also, take home challenges are probably very discriminatory towards older
> candidates with families. So maybe just as subtle way of age discrimination?

I see this sentiment fairly frequently, and TBH, it completely baffles me. I
am in my mid 40s. Yes, I don't have nearly as much energy nor desire to spend
all weekend doing take-home programming assignments as I did 20 years ago. But
if one candidate is willing to do more work and preparation for an interview,
that's not 'discrimination' \- that's one person showing they are willing to
put more effort into a job than another.

True, your family obligations may mean you don't have as much time to spend on
that preparation. If that's the case, that's a fine, very reasonable trade-off
you've made to prioritize your family over your work. But then it strikes me
as entirely UNreasonable to accuse businesses of discrimination because they
choose employees who have decided not to make that same trade-off.

~~~
jboy55
The whole bent against white board questions is that they are unrealistic as
to actual working conditions and thus are artificial. So if you are a
successful engineer, using your work time efficiently, and yet, you have
family obligations that prevent you from spending enough time as someone else
on a take home challenge, is the take home challenge showing realistic
'working conditions'? Or is it a measure of freetime?

>If that's the case, that's a fine, very reasonable trade-off you've made to
prioritize your family over your work.

I'd advise that if you are ever involved in a hiring situation you never write
that down. "I'm sorry my project wasn't done so well, [my baby, pregnancy,
illness, religious service] took most of my weekend".

That is a prime example of age/gender/disability discrimination. You should
never assume someone's out side of work life presumes an inability to do the
job during work hours.

~~~
hn_throwaway_99
The vast majority of jobs I've worked at have required some flexibility in
working off hours. Whether it was something that went down at off hours that
needed to be addressed, or an unforeseen (and unforseeable) change in a
business that required a last minute scramble, these things happen.

True, there may be some jobs that are truly 9-5, and if that's the case, so be
it. But frankly, as someone who is willing to put more dedication into my
work, it feels like complete discrimination against _me_ if someone willing to
do less work then demands the same level of compensation and advancement
opportunities.

~~~
jboy55
If 'Work Hours' require someone to be oncall 24/7, you can ask that as part of
your interview, but you can't infer that from other factors.

Yes: "Our job requires you to be on-call 24/7, one week a month, can you
commit to that?".

No: "You said you didn't have time for the take home test because you have a
family. The family will get in the way of 24/7 support"

Also yes: "you will be traveling 5 days a week for your sales job, can you do
this?" No. "We don't hire people with families for this job."

And, there's no discrimination towards you putting more time into your work.
That's quite a stretch, if all you have going for you is your ability to put
in more that 60 hours a week, that's not saying much.

~~~
kokokokoko
As someone who has been in this industry for a long time and seen a lot, this
still baffles me.

Who agrees to being on call 24/7 for a week? Especially when you are getting
paid a typical professional salary? It seems absurd. I've always been active
after hours and willing to jump in when things happen.

But this idea that you are essentially working (since you need to always be
somewhere you can start working within minutes) for a week out of a month
every month of your life for a salary job with no equity or long term payoff
on the other end, has to be the most bizarre choice a person could make.

Maybe there is something to that I don't understand? I guess if you don't have
any other interests or people in your life. But that just seems really sad.

Possibly someone who does this could help me to understand this a little
better?

~~~
jedberg
I've been on call most of my working life. When I worked at reddit, I was on
call 24/7/365\. The only time I wasn't on call was for the weekend of my
wedding.

When I got to Netflix, only being on call one week a month was a drastic
improvement. It meant that I could plan my vacations and important family
events around not being on call. On the flip side, my family understood if I
suddenly got up from dinner to take a call or get out my laptop. My on call
schedule was shared with the family so we could all plan accordingly.
Sometimes when it was my week and I had something really important, I would
ask a coworker to cover that night for me, and then do the same for them in
the future.

The salary for the position accounted for this inconvenience, and it wasn't a
surprise. Since everyone who does SRE has this same responsibility, it's built
into the compensation. Some companies actually give you extra money when you
are on call (I hear Google is one of them).

Yeah, it kinda sucks from a family perspective, but it is what it is. As long
as you set expectations with everyone around you, it's not that big a deal.

As it turned out at Netflix, since I was the lead, it meant that I was the
secondary or tertiary on call at all times, but again, the family knew this,
and also, my coworkers knew that if I didn't answer it was because I really
really couldn't take the call at that time, and everyone was fine with that.
It just rolled up to next person. Only the first on call was expected to
answer, all the rest of us were on a "it would be great if you could" basis.

------
acslater00
I ask most candidates to write code on a whiteboard in front of me and I’m not
apologizing for it!

The problem is usually fairly easy and if the candidate cannot get to a
“describe solution in words” milestone then I will guide them to one. After
that I ask them to write code. I will also tell them “the code is the part I
care about”.

The specific competency I am evaluating here is “can you turn thoughts into
code”. I repeat that phrase in interview training so much I think people make
fun of me for it.

Imagine I give you a python list with 100 elements and I ask you to write code
that will find all instances of the number “5” and move them to the front of
the list. I don’t care about performance.

You know you have to write a loop and whenever you see a 5, remove it and put
it at the front. Easy. Not even really an “algorithm”. Some people can make
code happen very easily and accurately. But some people really need to really
think about it - what control flow to use, off by one errors, bounds issues -
and make mistakes. Some people don’t see their own bugs. Some people do weird
stuff that makes me think they haven’t seen a lot of code before.

I teach interviewers to evaluate the act of the writing as much as the end
product, kind of like when airport security asks you “where did you stay in
New York” and doesn’t really care about the answer so much as how shifty you
look when answering it. It doesn’t mean you have to materialize perfect code
on the board to pass - not even close! But this exercise provides information,
and when other exercises corroborate that information we use it to make a
hire/nohire decision.

Anyway, bottom line is whiteboard code is a completely reasonable technique to
deploy in an interview setting and if you do this you shouldn’t feel bad about
it. Much more depends on (a) whether the interviewer is trained and calibrated
and (b) whether the company knows what it is even trying to evaluate than the
question format.

~~~
pmikesell
Thank you for writing this post. Whiteboard code interviews get a lot of hate
on HN and I suspect that folks who have come to rely on them for part of their
hiring signal have simply stopped posting.

I've done a lot of lower level systems work and the fact is that even with a
long career and history of very successful product I get whiteboard coding
interviews when I look for a job ... and it's just fine. Yes it's not the same
as day to day work, but it's related, and I have to admit that I find them
kind of fun.

Maybe there are 2 types of "programming jobs": 1) you will have to implement
data structures and algorithms, or 2) everything will be provided for you in a
language or framework. For job type 2) CS is not needed - it's not a computer
science related position ... it's "frameworking". I'm guessing that a lot of
the whiteboard hate comes from type 2) people applying for type 1) jobs, OR
type 2) companies asking type 1) questions.

For more history around whiteboard coding, there's the excellent "Why Can't
Programmers Program" post: [https://blog.codinghorror.com/why-cant-
programmers-program/](https://blog.codinghorror.com/why-cant-programmers-
program/)

I would like to actually figure out what is the bet way to do interviewing for
coding positions but it's super hard to actually have these kinds of
discussions on HN now without people getting upset at even suggesting
whiteboard coding interviews.

~~~
creato
> Thank you for writing this post. Whiteboard code interviews get a lot of
> hate on HN and I suspect that folks who have come to rely on them for part
> of their hiring signal have simply stopped posting.

It seems like there's a population of engineers that is perpetually
interviewing. I think the people that post significantly about this are people
that are struggling with frequent interviews, and correctly or not, lash out
at whiteboarding as why they are having trouble.

Maybe there's some large pool of otherwise qualified people that just can't
pass interviews and are being passed over because of it, but I really doubt
this is significant.

My personal opinion: I don't mind white board interviews. I'd do a take home
test, but I would prefer a traditional interview. And being a short term
contractor (also comes up frequently in these threads) as an interview process
is obviously impractical.

~~~
bfung
The pay in software engineering, esp. in the bay area, is very high. Companies
here never have enough engineers for one reason or other - the situation makes
current engineers always looking for higher pay regardless of their skill
level, and people not in the industry wanting to be in the high pay field.

------
paulmendoza
Whiteboard interviews are great, just not for writing code. I want to see how
you can communicate a design and have a discussion. So we always gave someone
a design problem where there really wasn’t a right way to solve it but lots of
ways. Then we asked them to tell us what they are thinking as they go thru it.
Some people just can’t communicate their thinking or think on their feet under
pressure. It was good at finding that.

I ended up trying not having it with some candidates and later I realized it
was a mistake. It would have given me some additional insights into their
communication skills I didn’t pickup on otherwise.

~~~
pmiller2
> Some people just can't ... think on their feet under pressure. It was good
> at finding that.

What was the relevance of finding that? Do you always do system design under a
strict clock at your company?

~~~
mtkd
In my experience some of the biggest problems are solved best by the slowest
thinkers

Those slow thinkers might have a good idea of the answer they likely want to
give straight away - but maybe want to take another day or two before
committing

Short meetings around a table can be quite frustrating for people that think
slow - which is why many discussions can reach a better conclusion using email
and time

~~~
IshKebab
That hasn't been my experience at all. The opposite in fact.

Sure the biggest problems aren't solved in 5 minutes at a whiteboard, but they
are solved by people who are _able_ to think on their feet at a whiteboard
discussion.

~~~
mikekchar
Not to put too fine a point on it, but when the decision is made on your feet
at a whiteboard, only the people who are _able_ to think on their feet at a
whiteboard discussion can participate. If you have a whiteboard discussion and
then say, "come back to me tomorrow with specific feedback" \-- and privately
ask people directly who you know are unlikely to make comments in public, I
think you will get a completely different point of view (if you haven't weeded
out all the good meticulous thinkers already, of course).

~~~
IshKebab
I think you missed my point. Hard problems are not solved at whiteboards
(usually). But the ability to "do whiteboards" seems to correlate with the
ability to solve hard problems.

------
wildmanx
Sorry, this is too black-and-white.

Of course it's stupid to ask somebody to write down red-black-tree rebalancing
algorithms from memory. Especially on the whiteboard without any
syntax/compiler help.

But given a more-or-less concrete basic problem that every programmer should
be able to solve with just basic knowledge of the chosen language hands-on (at
a computer, not the whiteboard) is a different thing. It can be a
collaborative process where the candidate can sketch an approach on
paper/whiteboard, then write code. While doing that they can query API
question to the interviewer, which, if they are doing a good job, will be
giving that information willingly. Watching the candidate building their
solution towards something that works tells a lot. It's not just whether the
code works. It's communication too. Code organization. How they think, how
they approach a problem, what to do when they get stuck (ask for help? run in
circles? just get confused?), what do do when their code has a bug etc.

Take-home exercises seem to be praised as the key solution, but I think that's
fundamentally flawed as already discussed here. If done badly, it's just as
bad as from-memory-whiteboard stuff. In-person-problem-solving can be done
quite well.

And the market proves that it works. Successful companies do it. If their
hiring would suffer substantially, then they'd have stopped doing it, because
their competition would have a substantial edge.

------
codingdave
Using a whiteboard, or even having trivia-like questions isn't the problem.
The problem is that people think those tools are trying to test your ability
to get the answer right. No. They are a medium through which you can see how
someone approaches problems, their thought processes, how they structure their
ideas, what they do when they get stuck, how well they communicate, how well
they understand directions, how well they dig for more information, etc.

None of those things has anything to do with whether you memorized an
algorithm or whether you got the answer right. Quite the opposite, slamming in
a memorized algorithm with the right answer has been a reason for 'no hire' in
my experience. Because all it shows is that you can code. And to work well on
a team requires so much more.

~~~
xfer
> Quite the opposite, slamming in a memorized algorithm with the right answer
> has been a reason for 'no hire' in my experience. Because all it shows is
> that you can code.

So the people who already know the solution to your problem are supposed to
pretend to have an "aha moment"? Really this is one of the reasons the process
doesn't work as well as you hope, people will memorize algorithms and pretend
to have that genius moment that you look for.

~~~
joshuamorton
Honestly, I'd much prefer if you tell me if you're familiar with the problem.

I previously interviewed at a company and of the three interviews, I knew, and
informed them that I knew, 2 of the problems they asked. I solved all 3 and
got the job, likely because after I implemented an lru cache in ~10 mins on a
whiteboard, we turned around and I actually coded it up in an ide, added
tests, and then we had some extra time to fix a few small bugs and discuss
caching strategies.

I'm still torn on the value of that interview though. And I'd much prefer to
ask you a question you don't know than to have you write down a rote memorized
answer, or pretend to be uncertain. I can usually tell and it wastes both of
our time.

------
faitswulff
As a candidate, here's what I like about white boarding, and conversely what I
dislike about take-home problems: at least with whiteboarding I'm guaranteed
to be wasting the employer's time and not just my own. I've spent hours
completing a code challenge only to be rejected with no explanation in the
past.

~~~
Ocerge
This is pretty much where I've landed; the filter can go both ways. If I make
dumb (minor) syntax errors on a whiteboard and it bothers the interviewer
enough to not hire me, or if the question is some "cycle a red-black subtree"
BS, I'd _really_ rather not work there anyway, and not have it take 4+ hours
of my personal time.

------
Grue3
A list of companies to avoid for sure.

Take home challenges are terrible. The worst I had was the following. I was
given the following prompt (translated into English):

"Please write a line-by-line sort of a large text file that doesn't fit into
memory. To test the functionality also write a generator of such files [...].
Programming language doesn't matter. It is recommended to spend no more than 4
hours on this task"

I quickly whipped up a solution (in like 1.5 hours) based that you can see
here [1] and sent it in. Obviously not "production-ready" solution, but it
uses the optimal algorithm and satisfies the sparse requirements that were
given. It didn't get accepted and the feedback was:

* the solution doesn't work with very long lines because CHUNK_SIZE is constant

* the solution stores the name of each chunk which technically makes it O(n_lines) in space (though the constant is very small)

Both of these are really uncharitable nitpicks, since the algorithm could be
trivially adjusted to take these into account were it a whiteboard interview.

And people are complaining about having to invert a binary tree? Get a grip.

[1]
[https://gist.github.com/tshatrov/3c862eced64b25dd4256c02e985...](https://gist.github.com/tshatrov/3c862eced64b25dd4256c02e985ec1e7)

------
hota_mazi
Instead of this subjective us/them mentality, I'd be more interested in some
hard data showing that not using a white board leads to higher quality hires.
I'm really not convinced this is the case.

Besides, that list is not what the title is. It's a list of companies that
don't do brain teasers. But a lot of them use white boards.

And to be honest, using a white board is important. You will be doing that a
lot in any kind of developer capacity, especially the more senior ones. You
need to be able to explain things clearly on a white board.

Factoring this in the interview process is a plus, not a minus in my opinion.

But we can all agree that questions should be about writing code, not brain
teasers. This has been a well accepted idea for more than ten years.

~~~
jfasi
> It's a list of companies that don't do brain teasers

Facebook, Google, Apple, LinkedIn, Netflix, etc don't do brain teasers and
they're not on this list.

EDIT: whoops, Netflix is on this list, my bad

~~~
nilkn
While the term isn’t very precise, in this context “brainteaser” means
precisely the kind of questions asked by Google, etc.

~~~
hota_mazi
Mmmh, no, I don't think so.

Brain teasers are typically understood as questions such as "How many ping
pong balls can you put into an airplane?", and other silly, non-coding related
questions.

This type of question has been banned in most tech companies for years.

~~~
nilkn
Given that you are the one who used the term, I’m curious why you used it in
the way I described then and not the way you just did. The article here
clearly is including LeetCode style questions as “whiteboard questions” — this
is explicitly stated. Maybe you hadn’t read the article? That is fairly
likely, given that your comments about physical whiteboards are addressed in
the article as well.

------
mikekchar
Where I'm currently working we do pair programming interviews (usually with
ping pong). Some candidates don't like it. Sometimes we have technical
hitches. However, it's been the best method I've seen in my fairly long
career. I can't think of a single time that we've hired someone and been
surprised when they showed up to work. The strengths we've seen have actually
been there and the weaknesses as well. We may well miss some good people, but
I think that's inevitable. Having a predictable hiring practice is much more
valuable to me.

Our practice is pretty interesting. We do a telephone pre-screen and then 2
hours of pair programming (4 25 minute pomodoros pairing with a different
person each pomodoro). We generally do the pair programming remotely. I can't
even remember the last time we did an in person interview. We also try to
accommodate people who want to interview outside of normal business hours.
It's a fairly long interview, but skipping the commute helps a bit (I hope).

Just for people who aren't familiar with ping pong, one person writes a
failing test, the next person fulfills that test and then writes the next
failing test. It ensures you pass the keyboard back and forth frequently and
that both partners are plugged in.

Like I said, some candidates really don't like it. There is still a lot of
stress having to produce while being watched. Also, not very many people have
experience with pair programming and TDD, so ping pong is pretty foreign.
However, the interviewer can help quite a bit, driving the process and even
solving the problem. Over the period of 2 hours, hopefully the candidate can
settle down and just program naturally. It also gives the interviewer a lot of
leeway to ask questions like, "What do you think of this idea?" and see how
they react.

~~~
brett40324
Thanks for posting! Your process sounds really great at getting to know and
feel how a candidate thinks and works with people.

Is the ping pong approach, tdd, and time involved communicated to candidates
before the interview date?

------
mykowebhn
Some companies list a take-home assignment as an alternative.

IMO, that's worse than a whiteboard interview. My time is valuable, and I
don't want to spend my evenings or weekends on an assignment.

~~~
rhinoceraptor
I think take home assignments _could_ be done well, but I've never seen it
happen. You often need to spend time setting up which is a total waste of time
for a throwaway project.

You should provide the candidates with a starter project in their language of
choice, already set up and ready for them to start working. And you should
give everyone at least some time limit (maybe one or two hours at most) so
everyone is on equal footing.

And the worst part is, all the take home assignments I've done are just used
as an initial filter, not as a final check in the interview process. I'd have
maybe one phone conversation beforehand, spend hours working on the take-home,
and then get a short rejection email with no useful feedback.

~~~
VonGallifrey
Why is a starter project so important that it needs to be provided by the
company and why in the language of choice of the candidate? How long does it
take for you to setup a starter project?

When I solved the challenge that we give our applicants it took me about 5
seconds to setup the project with everything I needed to solve the challenge.
In any language I use it does not take long at all to setup a new project.
Especially small ones like that.

~~~
rhinoceraptor
It depends on the language/framework you're using, something Rails would be
very easy to get up and running, but something like a modern Javascript app
SSR or Webpack, Babel, etc. might be very time consuming.

My point is your project should be a test of someone's actual
development/programming ability, not project setup. You don't want to have
people spend an hour configuring CMake or webpack.

~~~
VonGallifrey
The thing is though that we don't have the ability to setup starter projects
for any language that anyone might use.

For one thing because we don't know every language and every type of project
you might use. For instance I don't think we have anyone that could setup a
JavaScript SSR app. I certainly have no idea how that works. I am not a
JavaScript developer. If you want to solve our challenge that way then you are
certainly welcome to do so, but in that case you would need to set it up
yourself. If setting up a JavaScript SSR is time consuming or a major hurdle
to you then maybe use something else? If we where providing starter projects
JavaScript SSR wouldn't be one we would offer anyways.

CMake isn't that much to set up for simple projects if you know CMake.

I personally think it is fair to include project setup in this test, because
it will show me how well you understand the tools you use.

------
simplesleeper
I interview a lot of candidates and we do whiteboarding - to see how
candidates can communicate architecture designs and decisions.

The interviews have made me realise that countless candidates are unable to:

1\. Give a high level overview of a product

2\. Critique design choices and suggest improvements

3\. Communicate well as to what the value of components are to the broader
business.

Many of the developers can explain a particular piece of logic very well,
others can't even do that. But in an enterprise scenario, we need excellent
communicators.

~~~
vitovito
But communication on-the-fly, on-your-feet, in a high pressure environment,
which is what a whiteboard test is, is not most communication.

Most communication gets thought about, drafted, revised, critiqued,
socialized, ahead of distribution.

If your whiteboarding comes after hours or days of consideration and review,
that sounds like a great way to vet good communicators. Otherwise, aren't you
optimizing only for speed? If someone cracks a joke in the moment, they're a
wit; but we only pay money to and call comedians those who worked on it for a
while.

~~~
nxc18
Ever been in a tense meeting?

Most (almost all) verbal communication comes with time pressure.

Speak too long (ramble) and your message is lost and your coworkers are
annoyed.

Don't speak fast enough and now someone else is using all the air in the room.

~~~
JustSomeNobody
> Ever been in a tense meeting?

This should _not_ be what interviews are like.

~~~
deathanatos
If anything, my interviews are less tense and stressful than my meetings. On
_both_ sides of the table.

(If anything, this is probably not what _meetings_ should be like. I wish to
god my coworkers would have _real_ agendas for meetings — and a one-sentence
subject does not count as an "agenda", and ideally, written material detailing
any proposal that will be proposed, s.t. I can arrive at the meeting already
understanding what it is that someone wants to do.)

------
kappi
The theoretical coding interview based on undergrad CS topics has become a
cottage industry by itself with books,online sites etc. Very few people know
that this is used for indirect age discrimination to favor young folks. Not
sure when this insanity will stop. Human beings went to moon before we had
this coding interviews.

~~~
ummonk
And what makes older folks incapable of solving questions using basic
algorithms and data structures?

~~~
markmark
They've probably been working for 10 years without needing to write a sort
algorithm by hand since it's built into every language these days, and get
annoyed at having to re-learn it just for an interview.

------
grogenaut
Personally I prefer in person interviews as take homes take a long time and I
really only have time for that for positions I'm super interested in.

When I'm intereviewing people, I let them use what they're comfortable with.
If they want to use a laptop, fine, if they want to use the one we provided,
fine. If they want to use the whiteboard, fine. I can adapt. If they want to
use any given programming language, also fine, I can read most of them and if
I can't then it gives me a read on communication as they explain different
lambda or whatever syntaxes to me.

I will say (and advise candidates) that you should use languages you are most
comfortable in, and use what you're actually comfortable using for coding.
Don't do java because you heard company X uses java and you learned it this
weekend.

That said if you know python or ruby or similar language it's better for most
interviews with algorithms or string manipulation. If the coding question is
about byte arrays and memory allocation, c would be better. So I personally
will flip languages in an interview I'm taking.

Having given around 500 interviews in the last 3 years, I will say that when
people use computers they tend to focus on things like syntax more, as do the
interviewers. These things tend to get ignored more on a whiteboard or without
syntax highlighting.

I believe most mid to upper level programming interviews focus more on problem
solving and communication, which does mean that if you get hung up on syntax
(or the interviewer does) then you are burning valuable time on things that
don't really get you that senior level signal you are looking for.

Eg the more time you can focus on showing you can solve problems, communicate,
and design systems, and the less you are just arguing with the compiler, the
better signal the interviewer is going to get on your experience.

At the end of the day, the only real interview that can get a good signal is
working with the other person for a meaty period of time, usually several
months. Thus all interviews are are inherently an artificial evaluation. It's
just like taking standardized tests. You can get mad at the process or you can
just get over it and optimize for getting the highest evaluation you can.

------
nickm12
> Solving CS trivia, technical puzzles, riddles, brainteasers...

I never know what people are talking about when they complain about
brainteasers and riddles. In my career, I've interviewed at Amazon (x2),
Google (x2), Apple, Facebook, Pinterest, Dropbox, and Fitbit (5 offers, 3
hires).

At all of these companies, solving coding problems was part of the interview
process, as were systems design questions, and behavioral interviewing. At
none of them was I asked questions that I considered "CS trivia" let alone
brainteasers and riddles. Instead the focus was on problem solving, algorithms
and data structures, concurrency and other topics. You know, the things you
use as a working programmer.

I get that this interview style is not to everyone's liking, but to just call
it "bad interview practices" without either defining what it is or why it is
bad is lazy and unhelpful. There is genuine signal that comes out of these
interviews and the companies seem to be doing alright.

~~~
hizxy
Good for you?

------
alangpierce
They acknowledge that the term "whiteboard interview"/"whiteboarding" is a
simplification and a proxy for a style of interviewing they don't like, but I
really wish they didn't pick "whiteboard" as that simplified negative term.
Whiteboards don't get enough credit, from my experience.

I really like collaborating with someone with a whiteboard: it's fun, it's
social, and it feels like a dramatically more effective form of collaboration
and explanation than common alternatives like chat conversations and shared
docs. I've had jobs where whiteboard-style collaboration is common, and I've
had jobs where it almost never happens, and I greatly prefer to be in a
culture where it's the norm. So for me, if I go through an interview process
and no whiteboards were used in the process at all, it makes me worry that I
wouldn't be happy there.

------
MAGZine
There are a lot of companies on this list who list homework. I'm not sure if
this is supposed to be a selling point or not, maybe for some candidates. At
PlanGrid, we basically stopped giving homework because it wasn't respecting
either of the interviewer's or interviewee's time.

There are some exceptional cases when giving homework is acceptable/can be
useful, but if you're giving it to all applicants, you're certainly selecting
for an audience that has a lot of time to spare.

------
ajkjk
This makes me realize that a giant list of every tech company would have been
really great when I was last looking for a job. I looked for weeks for every
small company in the Seattle area and didn't find a few of the ones on this
list.

------
softwaredoug
Discussions of interviews always cast a practice as definitively “good” or
“bad”. The reality is it depends what the real job will entail. If the job
actually requires a lot of white boarding style problem solving, then why not
a whiteboard problem solving interview? If the job is a pure heads down coding
job, then a more heads down interview seems best...

~~~
ehsankia
Not only that, most of those companies probably hire a handful of people per
year, but not all of these methods scale to a company hiring thousands. Many
of these can also be easily abused and cheated.

------
seanmcdirmid
As a lefty, my biggest problem with whiteboard interviews is writing code on
the whiteboard. I just can't write text in straight lines very easily because
my hand is occluding it, and so I write slower and use more strength doing it,
getting tired pretty quickly. I have no problem drawing on a white board (I
draw my shapes in counter directions like most lefties), or writing simple
labels/lists, or whatever, but coding on a freaking whiteboard should be
illegal :).

And then they expect me to talk while writing code on the whiteboard...

------
gigatexal
Here’s a curve ball: has there ever been a study on companies that do be those
that don’t do whiteboard interviews and the relative performance of the
company or the staff?

~~~
solipsism
Absolutely. The giant companies who do whiteboard interviews have studied this
intensely, because making quality hires quickly is a critical part of their
business.

The people who say the industry should stop doing whiteboard interviews, in
contrast, have no data.

~~~
alasdair_
The giant companies who whiteboard are full of people who have a strong
incentive to reach the conclusion that the process that selected themselves
over other people is a good one.

Unconcious bias is a tough thing to control for.

~~~
solipsism
These companies are also full of Directors and VPs whose very jobs, and their
millions of dollars in salary, and their image as successful managers, rely on
successful hiring choices.

It's definitely not hard to imagine such people being biased toward
whiteboard. It's also not hard to imagine them hiring outside firms to conduct
studies and collect data.

Speaking of bias, there's a lot of it around here toward the idea that
whiteboarding is ineffective.

~~~
simplesleeper
"it's not hard to imagine that A" does not mean that A is happening. It
doesn't even mean that P(A) is high.

Your first paragraph also goes directly against what you are trying to prove.
If their success relies on good hiring, then they would pick the best methods.
If they haven't, they wouldn't be successful and would be replaced.

What a load of twaddle .

~~~
solipsism
If you can find where I have said that anyting proves anything else, then I
will certainly retract it. The only people talking about proof are those
setting up unreachable goalposts.

 _If their success relies on good hiring, then they would pick the best
methods. If they haven 't, they wouldn't be successful and would be replaced._

That's faulty reasoning. Successful hiring choices do not necessarily depend
on having used the most ideal hiring practice. Past success does not mean
things cannot be made better.

 _What a load of twaddle_

I know this topic makes people emotional, but how about we keep it civil?

~~~
simplesleeper
I do apologise. For a moment I thought I was talking to Alasdair. Having now
checked your name properly, everything you wrote previously is seen in a new
light and my post is the twaddle in this instance.

Agreed that things can always improve.

------
1e-9
I completely agree that having candidates solve trivia, puzzles, riddles, and
brainteasers on a whiteboard is an extremely poor method of evaluation.
Outstanding developers can mentally freeze when asked to solve even fairly
trivial problems in front of a critical audience. Having candidates use a
whiteboard to illustrate and explain details of projects or problems that they
have previously worked is far more productive. You then drill them within
their familiar context regarding their design choices and present them with
what-if scenarios that might have changed their approach. It is more realistic
and it helps put candidates at ease so you can better evaluate their thought
processes, enthusiasm, and practices. I cannot recall a real-world situation
where a developer had to solve a detailed problem in front of a critical
audience. In front of a critical audience, you either know the answer or you
say when you can have the answer.

------
Joeboy
I've been a professional developer for over 20 years and I've never been asked
to do anything on a whiteboard at an interview. I guess I've done at least 20
interviews in that time (but I can't really remember). Maybe I was just very
lucky. It's just as well as I have really shitty handwriting.

------
curtis
I wonder if the right thing to do is to simply give interviewees a choice
between whiteboard interviews and take home tests. I seem to be in a minority,
but I personally prefer whiteboard interviews over take home tests, but I can
easily understand why many people prefer take home.

~~~
bartread
To be honest, I wonder how much take home is for _your_ benefit rather than
the company's.

Hiring is extremely time-consuming and a big motivator for me to adopt take
home problems as part of our process would be that it saves time for people
who would otherwise be involved in interviews.

However, we're at a point where we're little enough known - and therefore
don't have much cachet as a desirable place to work - that I'd prefer to
invest the time in speaking with someone rather than send them a test.

It's all rather cold-blooded, which is unfortunate, but it's also the reality
of hiring and having to deal with large numbers of applicants relative to the
size of your team.

------
thoman23
From the article linked on the github site:

> "While the path to becoming a software engineer used to involve going to
> college and majoring in computer science, now candidates for engineering
> jobs also include autodidacts who taught themselves how to code and
> graduates of coding bootcamps, which teach web development fundamentals in a
> shortened period of time. This means non-traditional candidates can get a
> foothold in the industry without following a traditional path — but it
> doesn’t matter if they can’t get hired because of a fixation on memorizing
> trivia."

So now a computer science education is "trivia" and a one-month web
development bootcamp is equivalent?

------
neilv
One way that a takehome can align well with a business is when it selects for
people who are relatively strong at "introvert" activities.

Some of our work requires high-bandwidth face-to-face collaboration, with
ideas and decisions needed immediately, but a lot of our work is a natural fit
for being able to go off and think through a problem by oneself (for perhaps
the bulk of it; there's still interaction).

A takehome seems to favor someone good at the think-through part. (Although a
takehome doesn't fully exercise someone strong at this bulk part who also has
a sense of when to, say, bounce it off someone else, or ask more questions, or
get feedback at that point, or call in an intense group brainstorming.)

(Of course, some people can do, say, pair-programming all day, and it
energizes them, and that's great. Others, who we might roughly label
"introverts", would find all-day pair programming taxing, or distracting with
social awarenesses, or have a sense at times that they'd be better off
thinking at their own pace or in their own directions. Both kinds have merits,
and probably the organization wants some of both. My experience is that a mix
of them works on a team, even with some near the extremes, though the most
extreme pair types presumably need a mate to function.)

------
jheriko
if you find an interview in front of a whiteboard to be a high pressure
situation where it is difficult to communicate... maybe that is the problem
and something to work on.

it really is the case, then you are unsuitable for work in a lot of roles...
aside from that being able to communicate under pressure is extremely valuable
everywhere.

on the other hand... plenty of roles don't need this. sitting behind your desk
doing code is usually pretty different to anything you come across in
interviews :I

------
GuB-42
Are whiteboard interviews so bad that it justifies selecting companies against
it?

It may not be the most pleasant or effective interview technique but just as
candidates don't need to be perfect to be hired, neither are companies. It is
not a red flag, not even a yellow flag. Just a minor annoyance in the
recruiting process.

And while it may affect your chances of getting hired, out of arbitrary
criteria, it is is at least one you can do something about relatively easily.

------
pflanze
I've written a script to allow me to filter the list, using the Functional
Perl libraries. Maybe someone will translate it to JS?

[https://github.com/pflanze/functional-
perl/blob/master/examp...](https://github.com/pflanze/functional-
perl/blob/master/examples/hiring-without-whiteboards)

If you want to run it:

    
    
        sudo apt-get install libfunction-parameters-perl libterm-readline-gnu-perl libpadwalker-perl
        git clone https://github.com/poteto/hiring-without-whiteboards
        git clone https://github.com/pflanze/functional-perl
        functional-perl/examples/hiring-without-whiteboards --help
        functional-perl/examples/hiring-without-whiteboards hiring-without-whiteboards/
    

E.g. to search for companies that offer remote jobs but not also jobs in
London, UK:

    
    
        $cs->filter(fun($r) { $r->remote and not $r->locations->any(fun($l) { $l=~ /\bUK\b/ and $l=~ /london/i }) })->show_items
    

Disclosure: I'm the author of the Functional Perl libraries.

------
xivzgrev
If a take home assignment takes more than 2-3 hrs, or is one of those “spend
as much time as you like”, you’re in a not great situation. The mgr likely
doesn’t know exactly what he’s looking for, or likely doesn’t care too much
about employee welfare.

If you find yourself here, stand up for yourself. Say you have a number of
interviews going on and that you are happy to do a 2-3 hr assignment (the same
as an on-site interview).

------
city41
I work at Netflix and we most definitely do white board coding interviews. At
larger companies interview approaches will vary by teams and orgs.

------
tachyonbeam
There are many comments in this thread about whiteboard vs take-home
programming challenges. That's a false dichotomy. What I would really like to
see is an interview where I am allowed to code on a computer (at the
interview) instead of a whiteboard. I would like to be able to write real
code, and test it while I'm coding, as I normally do when programming.

~~~
ummonk
Yeah, this has started becoming the norm at a lot of startups - coding on
computer + design on whiteboard, and I think it works really well.

------
agoldis
"Take home" challenges are excellent - they give an opportunity to create a
common platform for discussion that every party feels comfortable with.

As for time investment, it's worth to dedicate 4-6 hours of your life to make
sure the next few years of your employment are good for both parties.

It is not whiteboard that is a problem, but pressure of being evaluated by a
random dude. It's like dancing naked. Whiteboard is a complimentary tool that
should be used for visualization and demonstration, that's it!

Also, it takes years of experience and a great emotional intelligence in order
to be able to conclude anything not obvious about a person after 1 - 1.5 hours
of f2f communication. Let's face it - most of us are not there.

The best way is to simulate a real-case dynamics of whatever the job requires,
for as long as possible, and give both parties chance to behave in a natural
way.

~~~
jboy55
All sounds great when you interview for 1 position at a time, but how does
this scale if I interview for 4-5 companies in my job search? Considering
every take home probably also has a full day interview afterwards, that's a
lot of time investment.

As a company looking for people, do you want to have your 6 hour take home
project to happen after the candidate has an offer? As a candidate, are you
really going to spend another 6 hours, if you have an offer in hand?

~~~
agoldis
It's your choice to interview for 4-5 positions, moreover, you will have those
interviews whatsoever, so it can't be an argument :) Most chances you are
applying for a high paying job and do that once in 2-3 years on average,
aren't you ready to invest a week of intense effort for that? If not, you
could choose to apply to a FAANG and spend 2-3 weeks studying craking the code
interview-style books. How much time do you think is reasonable to invest for
candidate and a company to make a decision? As a company I don't see a point
in giving home excercise after an offer, but why are you asking? I will spend
12 hoirs if I consider a company better than one that offerer.

------
Justsignedup
I am proud to say my company has a phone screen coding question 100% relevant
to the day-to-day work you do. And also all our coding / whiteboarding /
behavioral questions are geared to answer if you know how to handle challenges
that daily life in the company will bring, and what sort of person you are.

To come up with the right questions was a difficult effort. We definitely
avoid algo / puzzle questions like the plague, and the technical stuff we ask
is more of a discussion than a quiz.

So yeah, it is important to look for the right signals.

------
eiskalt
I didn't get in details, what kind of CS question should be eliminated in
"non-whiteboard" interviews. However, I would definitely ask at least basics
of algorithms, their analysis, and data structures. For example, in my
carrier, I saw enough getter methods (e.g. getCustomers) which looks from
outside simple/fast but internally do linear search on each invocation. It
especially "nice", if you have a piece of code which iterates over multiple
collections in nested loops on UI thread..

------
astura
In at least 20 interviews over the years I've never had a white board
interview, I assume that's mostly a west coast/SV/startup thing.

~~~
seattle_spring
If you don't mind me asking: How much do you get paid, and what sort of
interesting problems at scale do you get to work on?

The salary I make and the interesting stuff I get to work on is worth the song
and dance I've got to perform every few years, in my opinion.

~~~
astura
I wasn't making any claims about which is better, or even which I prefer, just
an observation that I've never seen East Coast established companies do any
whiteboarding.

~~~
seattle_spring
Mm'kay, let me rephrase the question:

What kind of companies were the 20 places you interviewed with, and what were
the typical salaries they were offering?

------
rachelbythebay
Laptop tests aren’t great either. Are you at your best on a dinky little
screen, goofy keyboard, and with the clock ticking? I’m guessing not.

------
cbanek
This is a great list, but I think it's more interesting than just "doesn't do
whiteboard job interviews" \- I like that each company has a quick breakdown
of their hiring process, which is even more useful. There's a lot more people
doing take home projects than I thought!

------
neatcoder
If whiteboard job interviews with clever algorithm problems are so bad, how is
it that successful companies like Amazon and Google do it and they are both
hugely successful?

------
randomacct3847
What is considered a teaser? I’ve done the Leetcode style questions and most
don’t feel like “gotchas” to me...

------
gamma3
I've interviewed engineers on computer science problems on a whiteboard and
those who did great turned out to do great on the actual job.

That's a one way implication. It is possible there are people who do poorly on
coding interviews but great on the job.

Whiteboard coding is simply a quick test that has few false positives in my
experience (around 40 interviews).

~~~
PunchTornado
many assumptions, few facts

~~~
yakshaving_jgt
There are few facts to make the case in either direction, so the anecdotes are
valuable.

Of course it's a bit of a shame that the one comment not subject to HN
groupthink is [predictably] all the way at the bottom of the page.

------
Waterluvian
I'd love examples of respectful, positive ways to decline a whiteboard
question.

~~~
rboyd
I recently read 'Developer Hegemony' and remember a section where the author
advised politely declining and suggesting that you may know some other
(implied lesser) programmers who might be willing to jump through the
arbitrary hoops.

Fun in theory. In my opinion this approach will work about as well as the old
"if we all stop paying our taxes they can't come after all of us" idea.

