Against The Whiteboard

Today’s computer programmers enjoy one of the best job markets that any group of workers has ever had. There are abundant well-paying opportunities for many different kinds of working coders. But we’ve seen a lot of programming culture, or the tech world in general, become overly exclusionary. One of the biggest reasons? The interview process.

A lot of tech recruiting and hiring is broken. Coders are regularly asked to jump through bizarre hoops in job interviews, and perhaps the most notorious example of this is that programmers are often asked to implement algorithms or complex coding structures in the artificial environment of a conference room whiteboard. Needless to say, that contrived requirement has started to engender a bit of deserved criticism.

In a world where we can often just find an answer to any coding question on Stack Overflow, we’ve started to see programmers push back against the idea that rote memorization of obscure syntax is a useful way to judge potential contributors.

David Heinemeier Hansson, the creator of Ruby on Rails, is many things, but falsely humble is not one of them. So it was particularly striking to see this tweet from him recently, where he described his inability to complete these kinds of whiteboard tests.

DHH’s confession kicked off a striking conversation where coders of all stripes revealed their own gaps in knowledge.

In fact, that conversation that followed eventually inspired dozens of coders from around the world to share their similar stories. You should take a look at these testimonials — they’re an incredibly rare example of people putting their reputations up for examination in an attempt to make others feel more welcome.

Of course, it’s important to note that even being able to confess to such shortcomings is a privilege that not every coder can demonstrate in today’s tech culture.

This dichotomy has played out in the tech realm many times, especially in discussions about impostor syndrome, which whiteboard coding tests seem perfectly designed to trigger. We’ve seen reassuring and thoughtful essays addressing impostor syndrome by coders like Gina Trapani, but these are often mirrored by underrepresented coders explaining that they can’t take the risk of even mentioning any gaps in their knowledge because their reputations are always at such risk.

It’s a stressful state of affairs all around, and it seems like right now, the whiteboards are only making it worse.

So why do we even *have *whiteboard coding tests as part of job interviews for programmers?

As it turns out, we can see one key reason that this became common practice at tech companies. Joel Spolsky, our cofounder at Fog Creek Software , who’s now the CEO of Stack Overflow, wrote a very influential post on interviewing candidates for his “Joel on Software blog” back in 2000 which includes (after a 2006 revision) the following passage:

Ah hah! So we should all just blame Joel for this bad interviewing habit and now we can get back to our work, right? Case closed. Well, not so fast. In the same piece, which was written eleven years ago, Joel included some very important context [emphasis added]:

It turns out, the point of this entire exercise was to inspire a thoughtful conversation with a candidate about the way they solve problems. It’s important to remember, Joel’s post was written in an era when the state of the art in technical hiring was still people devising more obtuse variations of Microsoft’s “Why are manhole covers round?” interview question. Worse, recruiters were (and often still are) the bane of most coders’ working lives, interrupting them while acting as unauthorized middlemen representing job opportunities that often weren’t even a good fit.

The whole area of tech recruiting was even more of a mess than it is today, and the idea of focusing on how a candidate solves real coding problems represented a huge leap forward in making interviews much more pragmatic and relevant. (This is probably a big part of why Stack Overflow is as focused on fixing tech recruiting as it is on answering coding questions.) But what was once a thoughtful effort has now become a huge source of pain, and maybe even more frustrating than the problem it was originally trying to solve.

Like a lot of cargo-cult tech trends, whiteboard algorithm sketching started to go horribly wrong when people started copying a behavior at a superficial level while ignoring the cultural and emotional context that informed that behavior. In short: **people copied **

In this case, instead of finding out how a candidate solves problems, interviewers ended up asking them to perform a ritual that’s mostly about reciting trivia. The immediate result is lots more stress for interviewees, and perpetuation of structural barriers for people who are already underrepresented in the tech industry.

Where does this end up? With even worse repercussions than we’d expect. More and more industries want to be like the “innovative” or “disruptive” high-tech industry. Yet they almost never have the fluency and literacy in technology to know exactly what aspects of tech culture they should or should not be emulating.

In the current political moment, this unfortunate pattern can result in the absurdity or even injustice, especially in institutions that are already looking for reasons to exclude and raise barriers. We saw this recently when we heard the story of a young, talented visitor to America who was reportedly asked to write functions to evaluate Binary Search Trees just after exhaustedly disembarking from a lengthy international flight.

While this case may be an outlier, overall it seems we’ve ended up close to the worst-case scenario: institutions are dehumanizing people by misapplying a well-intentioned interviewing process that had originally been designed to be more thoughtful and humane than the older questions it replaced.

It’s not too late to fix things. The first step is for us to look at the way interviewing and hiring work in the tech industry, and to make changes to our own processes. If the rest of the world is going to follow our example, then maybe we can cajole them into following along with us as we fix things.

Even though we’ve spent the better part of two decades thinking about this at Fog Creek, our own process is far from perfect. We’re spending a lot of time thinking about how to make sure our process is focused on how real people think, in realistic scenarios they might encounter during actual work, instead of asking folks to jump through hoops they’d never see in the real world.

More to the point, we’re paying careful attention to what we hear from the countless working coders who’ve spoken up about the differences between interview orthodoxy and a truly inclusive and creative environment. Some of that is building a company with a truly collaborative culture, and some of that is creating smart new tools that are inherently about enabling a diverse community to help each other code together in ways that are supportive and welcoming.

But that’s just our work at one company. It’s going to take all of us together to change a tech culture that’s too often turned onramps into obstacles. The first step to becoming more inclusive in interviews may be returning to exactly the principle Joel outlined in his seminal blog post: “my real goal here is to have a conversation about it”.