A listing of companies that don't do whiteboard job interviews

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?

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.

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.

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.

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.

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.

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...

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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.

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...

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...

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?

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.

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.

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.

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?

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.)

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

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.

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...

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.

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).

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

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.

"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.

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.

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..

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.

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.

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!

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?

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

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).

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