Programmers are confessing their sins to protest a broken job interview process
I&#x27;m conflicted about this. On one hand I agree with the idea that the best way to test whether someone can do something is to look at evidence that that can do that actual thing (i.e. write real code using best of breed tooling).<p>On the other, a whiteboard provides a very real constraint and tests something a little less tangible than can someone copy&#x2F;paste. A whiteboard test is not just a test of &#x27;can you solve this riddle&#x27;, but more about how you think and communicate your thoughts about software development. It&#x27;s this point I&#x27;ll defend below.<p>The example DHH gives seems like one I&#x27;d like to specifically call out. If you can&#x27;t write a bubble sort there&#x27;s some real problems. You&#x27;re unable to take a few hints about an implementation that are obvious from the name. It&#x27;s a sorting algorithm, and it the way it works looks like something to do a bubble otherwise why would it be named that way. Now I can&#x27;t exactly recall the algorithm, but that&#x27;s enough to make some guesses about how it works. Start at the first element of the list and bubble up the highest number we see until we get to the last position. Do it again for the second to last position, etc. Which leads to the following:<p><pre><code>    for (int i = 1; i &lt; len(list); i++)
      for (int j = 0; j &lt; len(list) - i; j++)
        if (list[j] &gt; list[j+1])
          list.swap(j, j+1)
</code></pre>
A good interviewer would understand a situation where a candidate was unfamiliar with the problem stated and be able to provide hints that would get them to this algorithm. A good candidate would not let the lack of knowledge of the algorithm deter them from attempting an answer by asking clarifying questions, and talking over how they think something might work. Software development is just as much about communication as it is programming.