Let’s Stop With The Whiteboard Interviews Please

no no no no…

Hiring is broken.

Whiteboarding Sucks.

Over and over, we keep hearing this yet nothing ever changes. Companies continue to use this practice and Engineers/Developers continue to complain until they get a job at which point they think of it as a shitty but necessary process much like a hazing ritual at a frat. I’m not the first to say it and I won’t be the last:

To be clear — whiteboarding isn’t the only problem. We are still wrangling with how best to measure an Engineer’s performance and asking Front-End Developers to inverse B-Trees rather than evaluating their understanding of the DOM is probably not a good strategy, but hey, it works to a certain extent. You filter for people who are willing to go through the tedious process of preparing for these questions which indirectly measures their commitment and passion to get a job which is somewhat correlated with how effective they will be at their actual job. It’s not ideal but it’s something.

But I want to focus on whiteboards here because I believe that is the low hanging crap that we can easily get rid off without compromising the traditional heuristics we use to hire too much.

I recently had one of the best technical interviews of my life. It was a phone screen and we used Coderpad which is a common online editor tool used by tech companies for this process. I had interviewed with this company (it’s a big tech firm ya’ll know) before and come up short at this stage.

But as we started this interview and got into the questions, something amazing happened. I was working through my code when the interviewed suggested, “why don’t you try running it and see what we get?”


I can run my code?! You mean I can approach this problem like the way I normally approach a problem?

I had done multiple Coderpad interviews before and, to my knowledge, it never had this ability; or to be more accurate, companies never chose to use this ability. A certain search engine company doesn’t even bother giving you a conducive coding environment and makes you use an ugly plain white doc word document to write code. WTF.

I would always find myself getting stuck at intermediate stages of a problem not sure how to proceed. My approach to coding is always to write something, run it, inevitably find a bug, and fix it. I don’t claim this is an efficient way of doing things. I don’t even know if anyone else does it this way. But this is how I code. And at least for me, being trigger friendly like this leads me to the right solution much faster.

Quick example: Say I want to find the number of Customers in each Country, only including Countries who have at least 5 customers.

Iteration 1

OK — cool. Hmmm….how do I get the count again?

select country, count(customerid)
from customer

Error 1: could not prepare statement (1 no such table: customer)

Iteration 2

Woops the table name is customers and not customer. Let’s fix that.

select country, count(customerid)
from customers
group by country

Yay I got some output!

Oh cool this gave me the count of each customer by country. Great — I think I am close.

Iteration 3

Hmm — ok now I need to just filter for Countries where there are at least 5 customers. How about this?

select country, count(customerid)
from customers
where count(customerid) > 5
group by country

Error 1: could not prepare statement (1 misuse of aggregate: COUNT())

Iteration 4

Ah! Something went wrong…wait I remember I can’t use where for count, I have to use having.

select country, count(customerid)
from customers
having count(customerid) > 5
group by country

Error 1: could not prepare statement (1 near “GROUP”: syntax error)

Iteration 5

Ugh now what? Oh dumb of course having comes after group by not before. Which makes sense because we use having for aggregate functions that are not part of group by…

select country, count(customerid)
from customers
group by country
having count(customerid) > 5

Yay! I got some output again! That makes me feel better. Let’s do a final check.

Iteration 6

Hmm — now that I look at the output I don’t see any countries with 5 customers. And we wanted to find all countries with at least 5 customers. Oh I see now! I need to just tweak the filter condition.

select country, count(customerid)
from customers
group by country
having count(customerid) >= 5

Woo hoo! I think that solves it! :)

See W3 Schools to play around with this code: https://www.w3schools.com/sql/sql_having.asp

Now…here’s the thing.

  1. I am not saying I make each and every mistake listed in this example each and every time. But I do make some of them some of the time. Chances are I am much more likely to make them if someone is going to be staring at me and scrutinizing what I am doing as I code.
  2. I am not saying you make these mistakes. Hey — maybe it’s just me. I’m not that smart and was not blessed by the coding gods like you. I have to struggle and wriggle and cry and sweat and all that just to get a basic count. I know. Sad.
  3. You might think ‘this looks painful’. But in reality if I am coding with the option to see how my code runs, the whole process for me to go from iteration 1 to 6 takes about…30 seconds. I got my mediocre coding process down you see. If I have to rely on someone else to review my code on each of these stages and offer me condescending dried up olive branches, ‘What do you think the Having clause is used for? Are you sure we get all the output we wanted from this query?’, then it becomes a much longer and more painful process. Not to mention the mental stress of having to ‘fix’ code so many times which makes you more stressed out causing you to make more mistakes and so on.

The point I am trying to make is: the difference between having the option to run your code vs not is much bigger than you might think. There are all sorts of mini-handicaps you put on yourself by not having this option and it is an unnecessary self-imposed limitation that you will in reality almost never have to work with.

And that’s how I felt during my interview. As soon as I knew that I could run my code, I switched into my ‘normal’ way of solving problems. I furiously ran my code at intermediate stages adjusting course depending on the output I saw on the right of my screen.

Sometimes — say for complex SQL queries, I like to run code just for one table and see the output. Just seeing the output makes me feel I am getting warmer and closer to the solution. It’s weird but it work for me. In Python — I love to use my beloved print statements at different places in the code to debug issues by seeing how the flow of the code worked for specific edge cases (‘oh I see why this case fails because we never hit this if statement…’).

In the end it was beautiful. I breezed through all of the questions. I was so proud of myself.

But before I could celebrate, I was invited for an onsite.

‘Yeah — you did great. So we are going to bring you to our office and make you write similar stuff you typed in an editor before down on a white board.’

Well — that didn’t go as well. And no it wasn’t just the white boards fault. I stumbled in places I shouldn’t have yada yada. But the white board did not help. It was weird trying to write code on a board, constantly erasing stuff and using arrows to ‘insert code’ in places I forgot. Also, for some reason I cannot write straight. All my lines were horribly slanted towards the upper right corner. Weird, but, who cares (ideally)?

I just did not understand why I had to go through this process of writing on a white board. Why couldn’t we use Coderpad at the onsite interview? We could share screens and go through the problem. Hey — we could even get fancier and project my Coderpad screen onto the whiteboard? We have the technology. Why not use it?

And so here is my plea to anyone in a position of influence running these tech interviews. Please — next time you bring a candidate in, give them a laptop and ask them coding questions. You can use the board to draw visuals like diagrams, star schemas etc. But let them code on Coderpad or an editor of your choice. At the end — instead of taking a picture of the white board from your phone, you can just save the file they had been working on for your reviews later on. You can even record the whole session for the hiring committee to go through later if you are so inclined. This process makes life easier for both you and the candidate.

It’s high time we go away from this dumb practice that everyone seems to hate, adds little to nothing in value, yet no one does anything about.