Whiteboard Interviews Suck, Get Good at Them Anyway

Most people agree that whiteboard interviews suck. They have little co-relation with the job requirements and thousands of great engineers are being rejected every day just because they don’t do well with CS 101 types of questions. On a flip side, the whiteboard interview have been the industry standard for many years and they are not going away anytime soon.

I personally was in the “whiteboard interviews are stupid” camp since the beginning of my career. While I enjoy solving puzzles, I felt frustrated by my inability to communicate true value that I could bring to the company. Instead of investing the time to get good at whiteboard interviews, I got angry and blamed the process, the company, the questions, or the interviewer.

While this approach did not stop me from being able to maintain employment, it did cause me to miss out on many interesting opportunities.

Whiteboard Interviews are Here To Stay

Whiteboard interviews have a very high false negative rate (rejecting people who are good), but they also have a low false positive rate (hiring people who are not good).

Prospective employers are operating in a very competitive space. A day or two of interviews is the only interaction they will get with a prospective employee, before deciding to spend hundreds of thousands of dollars to hire them. For this reason alone companies are much more concern with false positive, than they are with false negatives. Not hiring somebody who is good costs them 4-5 hours of lost engineering time (assuming they can hire somebody equally good down the road), hiring somebody who is not good can cost a lot more money in the long run.

There are a lot of great engineers who do poorly on the whiteboard interviews. At the same time there are few bad engineers (although they do exist) who can do extremely well on the whiteboard interview.

Assuming that companies are able to secure a steady flow of potential talent (and good companies can), it makes a lot of sense for them to stick with whiteboard interviews.

No hidden agenda

I used to believe that I got rejected after many whiteboard interviews, not because I did poorly, but because I didn’t have the same (right) background as the interviewer. I served in the military, I was a Front End Engineer, I didn’t go to a fancy school, I used the wrong language, I’ve used the wrong framework etc.

This false believe was shattered when I watched a friend of mine get an offer from Google and Facebook at the same time, and have two companies compete for the right to hire him. My friend did not have a fancy CS degree, actually he did not have ANY CS degree. My friend did not have a fancy blog. My friend had no following online. My friend did not speak English well, he only lived in the United States for 1 year. But my friend practiced and got really good at whiteboard interviews. This was literally the only secret to his success.

Biggest bang for the buck

My decision to start this blog was partially my reaction to hating the whiteboard interviews. I understood that potential employers needed a way to see that I can bring something to the table, even if I was not doing great at the whiteboard interviews. This blog did help, but not in the ways that I expected. I’ve expected that people would start reaching out to me saying something along the lines of “You are great, come work with us“. What I got instead was, “Your blog looks interesting, come interview with us“, LOL.

First few times this happened, I wanted to cry. Soon I realized that no one will hire me on the spot, unless I do something truly amazing. Having a blog or an open source project most likely will not result in a job offer. An interview offer, sure, but not a job offer.

If the brew is not cool enough to get somebody a job at Google, chances are some random blog or open source project won’t be good enough either.

Guess what IS good enough to get a job at Google? Being good at whiteboard interviews.

I love blogging and I wouldn’t give it up for the world. That being said, if my goal is to get more job offers, my time is MUCH better invested in preparing for the job interviews. Blogging is a great tool for sharing knowledge and motivating personal growth. It’s just doesn’t help nearly as much when it comes to career. Sure it can get me a bunch of interviews, but so can a well polished resume.

Investment that will continue to pay off

As I mention earlier, I started out my career as a Front End engineer. I’ve only been working full time in this field for five years. In that time span we went through at least three major revolutions in the technology stacks that we’ve used. When I started everyone was using Backbone and jQuery as their main tools of the trade. Then it seem like Angular 1 for a while was taking over the world, only to lose that spot to React a year or two later.

Why am I telling all of this here?

Because, unlike Front End tech, whiteboard interviews changed very little in the same amount of time. Even though I am senior Angular 1 developer now, very few people care. It’s old.

Have I taken the time to become a senior whiteboard engineer instead, the skill would serve me well for many more years to come.

Experience != Not Having to Whiteboard

I used to think that having a lot of experience would help me avoid whiteboard interviews. This might be true for leadership or architect roles, but it is not the case for regular software engineers.

I think one of the best times for me do well on a regular whiteboard interview was in my 3rd year in college, right around the time I took an Algorithms and Data Structures class. My brain was really used to writing out those types of questions fast and accurately in C.

By the time I was done with my Master’s degree and went to my first tech interview, I forgot all about it. I was surprised when I was asked to explain how I calculated time complexity of a binary search algorithm. I remembered it was log(n), but the math behind it (in my mind at time) was long forgotten as useless information.

Today I see a lot of similar surprise/annoyance/eye-rolls when I interview more experienced programmers, only to see them struggle through implementing a very simple whiteboard question a minute or so later. Perhaps I am the bad guy for asking a whiteboard question. At the same time, it is the best tool that I have to avoid giving false positive in 45 minutes that I have to get to know this person.

Years of experience will help a person get hired, but only assuming that they can do as well as other candidates in their interview. If I had to choose between an alleged experience or a good whiteboard performance, I would choose good whiteboard performance every time. I believe so would most other interviewers.

Don’t leave opportunities on the table

If I could go back in time to my Junior year in college, I would pay extra attention in my Algorithms and Data Structures class and I would invest a lot more time to help me prepare for whiteboard interviews.

I did OK in my career up to this point. I got to work in good companies with some interesting people. That being said, there is no doubt in my mind that I have missed out on a lot of opportunities in the past five years, because I did not invest enough time into getting good at whiteboard interviews.

That is a mistake that I plan to remedy going forward. I would encourage everyone, from a freshman in college to an experienced software engineer, to do the same. Wether we like it or not, there is no escaping whiteboard interviews.

Resources

Programming Interviews Exposed

A lot of other books try to provide sample problem and solutions, a task that is better left to online programs. Programming Interviews Exposed instead gives a good overview of everything that a person is expected to know in an easy to digest format. If a person could read one book before their next interview, I would highly recommend this one.

Algorithms specification on Coursera

I took the first two courses of Algorithms specification on Coursera (and so did my friend who got a job offer at Google and Facebook). It’s a set of video lectures recorded by a Tim Roughgarden, a Computer Science professor at Stanford. I highly recommend it, especially for engineers who do not have a formal CS background.

Online Coding Dojos

There are many interview preparations programs out there, but the two that keep coming up for me are Hacker Rank and Leetcode.

Conclusion

I’ve asked a lot of engineers who do well on their whiteboard interviews how they prepare, and the answer is always the same – practice.

My drill instructor used to say that “perfect practice, makes perfect”. This makes as much sense for military drill as it does for preparing for whiteboard interviews.

Whiteboard interviews are here to stay. We might as well accept this as a fact and learn to use it to our advantage.

An interview is just a game. A game that follows a certain set of rules, has very big prizes, and takes practice to get good at.

Comments

Why not use a computer to implement the code instead of a white board? Think of the benefits. You have an opportunity to see how comfortable the candidate is with the IDE & debugging code. Even more important, you can see how well the candidate can write a unit test. Do they have a bug in the code and was their unit test able to catch it? If so, you have a golden opportunity to watch them fix it in real time! This happens all the time on the job.

The problem with saying:

“If I had to choose between an alleged experience or a good whiteboard performance, I would choose good whiteboard performance every time. I believe so would most other interviewers.”

is that you are actually helping to promote the use of white board interviews. Is that your intention? If an organization feels that they must see how well a candidate can code in real time, then at least give let them use a computer (or ask the candidate to bring in a laptop) for this. But, as some others here have mentioned, a take home test is a much better way to identify a talented software developer. According to the article title The Hiring Post, https://sockpuppet.org/blog/2015/03/06/the-hiring-post/#worksample:

“Here’s a work-sample test we used: we built an electronic trading system in a single-file Sinatra project. We made its interface a custom binary protocol. We built an extremely rudimentary web interface that drove the protocol. Then we had candidates find flaws in the trading system.

Candidates need to code to attack this system, because there’s no off-the-shelf tool that speaks the wacky protocol we invented. They need some insight to see how they can get their hands on the raw protocol messages to reverse. They have to be comfortable diving into a piece of technology they’ve never seen before. They need to put all those attributes together and use them to kill a trading system

This test is a couple hundred lines of code, written in a few hours. It out-predicts any interview we’ve ever done.”

I am definitely NOT trying to “promote the use of white board interviews”, but I am trying to point out that these types of interviews are likely to stick around for a foreseeable future. Developers (like myself) who are avoiding preparing for these types of interviews, are doing themselves a dis-service in the long term.

Take the time to consider that you might be wrong in your assertions. WBI produces a negative experience for the candidate unless the candidate has spent time studying and memorizing (the keyword is memorizing because no one is going to invent core comp sci concepts on the whiteboard in a 30 minute session), which brings up the question: why do experienced programmers who have published work and many years of experience have to prove themselves on the spot by taking a memorization-based test every time they apply for a new job? Think about it. Do CEOs have to do that? Does any highly paid MBA business person have to do that? Even doctors and lawyers don’t have to take a test every time they have to get a new job and they’re dealing with people’s lives. There is something truly broken here. I don’t know what it is exactly but it is definitely a symptom that something deep down in the psyche of those who choose WBI for interviews. Fear of strangers? Wanting to prove that the candidate can memorize algorithms and spit them out on demand like a machine? I don’t really know. All I know is that many of the big companies are moving to take home projects and this trend will continue because the alternative is not working too well.

Well written article. Title is a tad misleading, I thought you’d actually have tips and tricks…

Overall, I see your point, but I still feel the interview process is completely broken and not just WBIs. It’s broken on numerous levels, but I’m just going to address WBIs here as that’s the core argument.

I can say that on a take home exercise (8-24hr turnaround) I demonstrate:
– incredible aptitude
– hard work
– efficiency
– attention to detail
– quick turnaround times
– great coding
etc.

and in a WBI I demonstrate:
– slow, under-pressure thinking
– uncertainty
– difficulty articulating
– unfamiliarity
– lack of memorization
etc
in a strange environment with people judging you every step you take.

It may not sound like it, but day-to-day I am a confident, mildly extroverted, articulate, and competent person. Artificial settings distract people from demonstrating their core competencies.
Practice would solve 90%+ of this. I know that very well, but I’m an engineer not a lawyer, let me get into my zone in a comfortable setting and knock your representative problem out of the park and get it back to you just like you would want me to on the job.

Anyways, that’s an argument against WIBs and for take home problems. There is a mild amount of inherent risk in take-home questions that is not present in a WIB, but I think the gains of respect towards individuals is worth it and the reduction in false positives – too high and it costs a tremendous amount of money (who’s measuring that?).

As a practical person of the world, on the occasions I go to interview, I practice. What you’re saying and I agree with (as long as WIBs cont to exist) is a more comprehensive approach should be conducted for the long term marketing of your skills as a product is necessary.

With all that said, my core tenant/belief, is that WIBs should not be necessary for reasons I’ve stated.