Long live Google

Developers rise against whiteboard interviews

Gabriela Motroc

David Heinemeier Hansson (DHH), the creator of Ruby on Rails and founder and CTO at Basecamp, started a Twitter revolution against whiteboard interviews when he tweeted that he “would fail to write bubble sort on a whiteboard.” This confession-turned-trend has been embraced by a huge number of developers who protest the controversial whiteboard interview style.

Hi, my name is (x) and I’m an alcoholic a developer who doesn’t know everything by heart. The war against whiteboard interviews is hardly new — but developers’ frustrations against this interview style were brought back into the spotlight by David Heinemeier Hansson (DHH), the creator of Ruby on Rails and founder and CTO at Basecamp.

And then the ‘fire’ spread.

…and the list goes on.

You are not a *real programmer* if you fail a whiteboard interview

DHH explained in a Medium post that interviewers should not put developers in the “big ‘software engineer’ basket because a programmer working on a new database storage engine doesn’t share that many overlapping concerns with a programmer writing a new web-based information system.” He confessed that he did not think he could become a “real programmer” because he thought that all programmers needed to love algorithms and pointer arithmetics.

Everything changed when he met Ruby, which “actively encouraged him to embrace programming as the pursuit of happiness at my preferred level.”

The world needs all kinds of people with all kinds of fancies. This is no less true for programming than for any other field of expression.

DHH is not the only one to condemn the use of whiteboard interviews; Quincy Larson, a teacher at Free Code Camp, wrote in a Medium post that hiring is broken because of the whiteboard. “Virtually every developer I’ve talked with agrees that one’s ability to write algorithms from memory on a whiteboard has almost nothing to do with real day-to-day developer work,” Larson wrote.

Although you can prepare for whiteboard interviews — Larson suggested Cracking the Coding Interview, “the closest thing to a whiteboard interview playbook” —the element of time pressure and the lack of an actual code editor that would allow you to run the code to see if it works could be a recipe for disaster. 

Why do tech companies still use a whiteboard for coding interviews?

According to a Quora thread titled Why do tech companies use a whiteboard for coding interviews when they could instead use a laptop which is projected onto a screen so everyone in the room can see it? this type of interview is still a thing because interviewers want to see if interviewees “can coherently and cohesively explain to them technical concepts.” Dima Korolev opined that “whiteboard makes it harder to make mistakes and quickly fix those” and added that “it’s a good environment to force one to really think. And talk loud.” Furthermore, “being able to stop, think and produce the result w/o much trial and error is a good trait,” he wrote.

Mani Gandham said that “whiteboards don’t need any setup, they can be seen by everyone, can be worked on by multiple people simultaneously and are easy to erase and edit.” Last but not least, they “force you to rely on what’s in your head.”

Aideen NasiriShargh opined that interviewees “should be able to sell their ideas using the minimum equipment.” He added that the lack of IDE will prove exactly how fluent you are, the lack of a compiler requires more confidence and the fact that it is inconvenient will show if you are mediocre or excellent. “The difference between the mediocre and the excellent programmer shows up when the build system is broken, it’s someone else’s decision, and we are under a heavy push to ship — exactly like here,” he wrote.

SEE ALSO: How often do programmers Google their way out of problems?

Solutions

This is definitely not the only solution —remember the above-mentioned book— but it’s something designers can use: whiteboard design challenge framework. Adhithya Ramakumar, Product Designer at OpenDNS, San Francisco, wrote in a blog post that while he was preparing for whiteboard challenges, he noticed that he was all over the place initially.

To get better at whiteboard challenges, I devised a framework from my design process that highlighted salient considerations to be made while designing.

The framework consists of two parts: the quadrants and the experience. “There’s no hard and fast rule that these steps need to be followed in any particular order, but structuring the session linearly helps with your thought process, and also helps with keeping people on the same page,” Ramakumar wrote.

Although Ramakumar’s example is suited for designers, he does offer a great piece of advice which will work in any situation: “Remember, they are not judging your solution, they’re observing how you think.”

Author
Gabriela Motroc
Gabriela Motroc is an online editor for JAXenter.com. Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

Comments
comments powered by Disqus