Whiteboard interviews are dead. Adapt, or get left behind
March 7, 2017

Whiteboard interviews suck, you don’t need to be told why.

What is your main goal in interviewing candidates? If you answered “to hire the best candidate” you should reconsider. Forming the best team is a goal that will better serve your company. Whiteboard interviews have been prevalent for over 25 years. But, ask any engineer and they would clearly state their preference in being tested on things the actual job requires. 

Data Structures aren’t everything.

We have known this for a fact: interviewers ask questions based on data structures. Considering the fact that Data Structures is a major part of every computers course, it does make sense. But does it make sense to ask someone to write up code on a paper/board?
Most recently, a senior developer Celestine Omin was held by the JFK Airport immigration. And this is what happened:

While the act of stopping him randomly just to verify his profession was in itself a questionable act. Let us look at the finer details. Of all things possible, they chose to ask him a Tree related question. Something that gives you an interview feel, right? This is exactly how most recruiters think like.

Since the Omin incident has happened, many senior developers from reputed organizations are confessing about their usage of the internet on a daily basis to refer CS fundamentals.You can refer this article by the outline to find all the major mentions from twitter. Truth is, there is no shame in doing that. Knowledge of data structures is important, yes. But then, it is not going to be part of your daily job to write out programs for trees on a whiteboard. We are humans, and there is a reason documentation exists. Unless there was an apocalypse which destroyed all documentation and every developer’s hard drive, I do not see any reason why developers have to know the codes of all data structures by heart.


Not only is it archaic, it also reduces the diversity of the people you hire. Whiteboard interviews are favoured towards young college graduates with CS background. It only helps you gets one kind of tech talent, and for the success of any firm, that is not beneficial. The most creative people (the problem solvers) are the ones who come up with new things. They can look algorithms and structures up, because they are trivial to them. And these are the kind of people you want to hire. When you worry about the more important things, you can choose the ignore the simpler ones. But unfortunately, major companies do not seem to agree. 

A quick peek at what A1 developers think

Joel Spolsky, cofounder of Stack Overflow, echoes this advice, adding “if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they’re so smart, don’t worry, they’ll get lots of good job offers.” . This would be reassuring if false negatives were random and nobody experienced more than a few. However, if an entire industry’s interview processes are biased against a particular group of people, members of that group will have a hard time getting hired anywhere, regardless of how talented they are. And “false negatives” is what “Whiteboard Interviews” are notoriously famous for.

 data structures aren't everything for a job

More and more companies are moving to an alternative technique of testing engineers before hiring them. Some of them even get prospective hires to work with them for a couple of days. But the change is coming slower than needed. And more talented developers are losing out on amazing opportunities because of this.
Startups are embracing a newer method to pursue interviewing, but the power houses aren’t. And this needs to change. Kids dream of getting into Google, Microsoft, and see them as the symbols of change. But as Max Howell mentioned in his tweet, 

He had done more than enough to prove his capabilities by building Homebrew (used by Google). But because he failed to remember how to invert a binary tree on a whiteboard, he was rejected. This is something anyone can accomplish with help of stackoverflow or a similar website. Is it really worth it to let go of someone who has made a product that’s being used by (almost) your entire workforce because of this one thing?
Developer Yegor Bugayenko (the author of a highly rated book about object oriented programming) writes about the huge waste of time when Amazon flew him out for an interview that consisted of 4 hours of whiteboarding algorithm questions. If the recruiter had said, “We’re looking for an algorithm expert,” he would have declined and both he and Amazon could have avoided wasting their time. “Clearly, I’m not an expert in algorithms. There is no point in giving me binary-tree-traversing questions; I don’t know those answers and will never be interested in learning them,” Bugayenko writes.


Knowledge of fundamentals is important for a job. That is fair enough. But think of this, is that more important than getting engineers who have the mettle to produce more than most.

So what are the alternatives?

Well, this is something that companies are experimenting with. More and more companies are willingly trying new and different things out.

As a testament to this fact, it is clear that there are more than a few alternatives to the rigged whiteboard interview on the table.

The following alternatives should give you good enough idea on how to proceed:


Give candidates work relevant to their actual role

Include things that the developers would be doing on the job.  As mentioned before, there is nothing better than getting an idea of the person like having him do the actual work. Under correct supervision, you will more often than not find out if the person is worth taking in, and if he/she is a team player and can fit right in. This investment is much better and fairer for you as well as them.

Take this example, if I want to hire a web developer for my team, and I have a project that requires some attention from a developer. It would be great to find out how this person would be working with my developer to come up with a solution. This also gives me a more than brief estimate of how well they gel with my existing team members. I get a ready project code to test them on, and I also find out if they are actually interested in the work we offer. Because it is never a one-way street, it is always important to know if the person likes what we have to offer as well. And in many cases it may be too late before you find out things for the worse. It’s better to be safe than sorry. And in case of critical hires, it’s 100 times more important to not be sorry.


Give them Take-home Assignments.

The thing with Take-home assignments is you give the candidates the comfort of their home to work at. Many might consider this a bummer, because they eventually have to work at your workplace. That is true, but nervousness hits the best of the developers, and specially when it is an important interview, I’d be willing to bet it is just about normal.takehome assignment

The other great part about this entire thing is you can choose to provide assignments that reflect what the job will entail. So what info this provides you, is when the developers gets comfortable, how much of a contribution can he/she make to your team. Because the initial few days might not be the absolute factor to decide either. When you give time to work on something that actually relates to the job, and give them the familiarity of their home to get it done, the results are usually much better.

Try to keep these things in mind though.

  • Ensure a fixed timeline. Ask what time they want the assignment handed to them. Share the assignment a good ten to fifteen minutes post that time.
  • Send something that gives a clear idea of what the work will involve.
  • Make the deadlines clear. Ensure that you give sufficient time, but not too much time for them to slack off either.

You might however run out of take-home assignments to give to prospective hires. Xobin has an arsenal of over 500 readymade questions that will suit each one of your needs. Click here and try Xobin now to revamp your hiring.

Extension of Interviewee’s Past Projects

Interviews typically involve putting the applicant through multiple rounds of grinding tests . Applicant’s often under-perform in such stressful situations. A good way to conduct the interview process is to keep applicants in their comfort zone. This is something I have not seen a lot of companies adopt. The idea is to take an existing project of the applicant(let’s take an android developer in this case), and remove a couple of functionalities from this project. Get developers to code back the functionalities to complete the project again.


A quick code review can give a good idea about the Quality of coding, naming conventions, unit tests and ability to write scalable and extensible code. The interviewee owns the entire previous codebase hence they are in their comfort zone as well. This enables the interviewer to get  a first hand idea of their working style.

Fact of the matter is, there is no one clear way of finding the best match. If there was, everyone would be using that. So it falls to us to keep working on new and more radical methods in order to discover the one that works best for us. Remember, what works for me does not necessarily have to work for you. And that is why you need to figure out your own sweet spot.

All things considered, Whiteboard interviews maybe were a good idea back in the day. But now their use is more than questionable. With many alternative options in recruitment technology that allow pair-programming and video interviewing, there is barely a need to fly a person in from a thousand miles away for a whiteboard test.

Xobin offers a complete suite, which test developers based on actual take-home assignments and product based questions that assess them to the best of their abilities. It also lets you interview while testing developers at the same time.


And for developers who have to go ahead and face the dreaded whiteboard anyway, please refer this blog by Patrick Collins of Google.

Technical interviewing for people who suck at algorithms