Developers rise against whiteboard interviews
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.
Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don’t do riddles.
— DHH (@dhh) February 21, 2017
And then the ‘fire’ spread.
@dhh Hello, I’m Rebecca. Whiteboards suck. I can’t hold a marker for over a few minutes, I can type nonstop. I wrote Bard’s Tale III.
— Rebecca Heineman (@burgerbecky) February 28, 2017
Hello my name is Mike, I’m a GDE and lead at NY Times, I don’t know what np complete means. Should I? https://t.co/QbrNDBZXs8
— Mike Nakhimovich (@friendlyMikhail) February 21, 2017
Hi, I’m Marijn, I wrote a book on JS and also CodeMirror. I never get functions right on the first try, & would fail a whiteboard interview.
— Marყ̈n Haverbeke (@marijnjh) March 1, 2017
Hi my name is Josh. I’ve programmed since 90s. I forget how to do subprocesses in Python & when to use java’s CyclicBarrier/CountDownLatch https://t.co/FuFs53EQ31
— Josh Long (龙之春, जोश) (@starbuxman) February 27, 2017
…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.
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.”