Whiteboarding

Hacker News is pretty great, everybody. I find so much interesting information there., and there’s very little trolling or other annoyances. A question recently posited that using whiteboards in technical interviews is “covered ageism”, and it got me worried about our (as in, my employer’s) – well, and also my – interviewing practices.

The gist of the idea is that whiteboard interviews, as they have evolved from their humble and well-intentioned beginnings, are exercises in regurgitating obscure computer science topics, on a medium (plastic-coated … what is a whiteboard made out of? that stuff) that you barely ever use in real life, without the usual tools at your disposal, like, say, the internet. Or at least Stack Overflow. They are also stressful, and don’t do a good job of testing candidates – excellent ones flunk such interviews and terrible ones who’ve crammed ahead of time (and had the luxury of time and/or money to do so) pass. Read more here:

There are a host of articles arguing why whiteboarding is awful. And yes, they created the term “whiteboarding” as a parallel to “waterboarding”, a form of torture by everyone’s standards except the United States government, apparently.

When I interviewed for Cloudera nigh upon six years ago, I was whiteboarded several times. In a row. Now, apparently I did well enough in the experience, since I’m still employed there. Looking back, I thought it was fine and not outrageous. But, I think that’s because my interviewers did it the right way. It was more open-ended questions, probing, working out solutions together, just seeing how I’d deal with unexpected things, or how I’d try to apply what I know. This is, from what I understand, how it’s supposed to be done. It was a mental workout for sure, but for my experience, far from torture. So, props to my interviewers.

I also opted to embrace the experience and just roll with it. I could do that because I was confident and mature enough that if I didn’t know something, I’d be OK with admitting it and just doing my best anyway. I can understand that being super hard for others to do. It can be a high-pressure situation!

Being remote, I seldom can conduct a whiteboard interview. Instead, we set up a collaborative online coding tool, like Codebunk, and then the candidate and I coordinate over that, and the phone / Google Hangout. Already this is much better than using a whiteboard, because hey, we’re typing out code instead of scribbling with markers. According to the whiteboarding stuff, though, it’s otherwise just as bad.

However, I always emphasize the same points:

  • This isn’t a homework assignment. We should be talking and working it out together.
  • I don’t expect us to get to a “correct” solution. I don’t expect us to finish.
  • It’s fine if the code doesn’t compile. It can be a weird hybrid of languages if that helps to get thoughts down.
  • Don’t worry about remembering the Java or Python or whatever API. Imagine that the functions you need exist, if you don’t recall what they are exactly.
  • When there’s ten minutes remaining in our time, I just stop the coding so that the candidate can ask me questions. I care much more about that.
  • We, we, we. It’s not me versus the candidate.

Essentially, I attempt to bring the stakes way way down, so that the candidate is comfortable and we can, you know, work together and communicate. I learn a lot about them just from 20 – 30 minutes of collaboration, especially whether they can code well. It doesn’t matter if they can finish some queue implementation perfectly, especially in that limited time under that pressure. How many people thrive in those conditions? I don’t. Do you?

Did you know I still don’t know how to do red/black trees? I never learned that. My computer engineering degree curriculum somehow missed them, I must have learned about digital microelectronics instead. Still, since I don’t know red/black trees, should I not have been hired?

One argument against whiteboarding is that it selects for younger candidates, fresh out of school and remembering all the obscure algorithms from their CS courses. People who’ve been working for a couple of decades don’t use that stuff and can’t reproduce it on the fly. And why should that be necessary, because I can Google “red black trees” and immediately find: an introduction, the Wikipedia article for them, and several YouTube videos. So I don’t need to know them … just of them.

This is where the “ageism” argument comes in. Older candidates don’t remember that stuff, because it’s not important to, as it turned out for them. There’s also the fact that some concepts hadn’t been invented yet, when we oldsters were in school. Here’s one: the CAP theorem was introduced in autumn of 1998. I had already left graduate school and started my first (crappy) job by then. Now, I did learn about it since then, but not in a school-y way … which is exactly what the wrong sort of whiteboard interview demands.

Am I worried about ageism? I am watching for it. It’s the only form of discrimination you should be lucky to have to deal with.

So, these are the thoughts swirling in my head. I’m wondering if this is a good time to look into alternative interviewing techniques for my employer to adopt. I’m not fully convinced that whiteboards and collaborative coding are always awful, but that doesn’t mean we can’t be on the lookout for something newer and better. Just like computer science topics that we might use in our work … or interview people about.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s