Programmers are confessing their sins to protest a broken job interview process

They're equally competent except that they can't design an algorithm on demand based on remembered strategies for solving problems, or talk intelligently about the trivia of the field that can come up in a technical interview, or tell you the asymptotic running time of a given algorithm, or comfortably rattle off a bunch of code from experience without needing to look things up online, etc.

That's not the same as being equally competent.

Whiteboards are useful for conversations about software architecture, but that seems to be the less common application in interviews.

Writing pseudocode you've memorized from a book is fundamentally meaningless. You have to realize it isn't really a programming test: it's a filter for whether you're willing to do what's required to fit in.

The principle is the same as in classic British private schools where boys were required to memorize long passages of ancient Greek and Latin texts. In fact, tech companies would probably get the same hiring results by replacing Cracking the Code Interview with Ovid's Metamorphoses, and asking about Phaethon's fall instead of binary trees -- the substance doesn't really matter. (The non-whiteboard parts of the process would do the same job as they currently do of ensuring some degree of practical software competence.)

I don't think the technical test is a problem per se, it's the way we implement it in our field.

I think it's perfectly reasonable that actuaries take an exam that shows knowledge of vector calculus. I don't think it would be reasonable to ask a senior actuary to do vector decomposition in an interview, because he or she has already demonstrated this ability on a proper and widely vetted exam.

Similar things go for medicine. Totally ok to have boards and exit exams, crazy to be asking these questions of a radiologist with 20 years experience during an interview. Same for lawyers. They must take the bar, but the don't have to retake the bar every time they change jobs.

In programming, we have no widely recognized, properly vetted, industry credential. So we leave it to private companies, who subject applicants to some variant of an industry exit exam over, and over, and over. And what's worse, they do it in secrecy with minimal feedback to avoid lawsuits.

It's horrible, and if the industry is experiencing a "shortage" of candidates, that's a good thing. It's a sign that things need to change. The government should not rescue this industry from the consequences of their actions by creating special programs that allow corporations to force would-be immigrants to subject themselves to these interviews and work in this field as a condition of living and working in the US.

Let people be free, and they'll make their choices. If tech is too abusive, then they'll either have to go without workers, or change. But seriously, take away this crutch of employer controlled visas. I'm not saying don't let talented people into the US, I'm saying let talented people decide how and where they'll work, don't let corporations control that and dictate their choices.

I'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).

On the other, a whiteboard provides a very real constraint and tests something a little less tangible than can someone copy/paste. A whiteboard test is not just a test of 'can you solve this riddle', but more about how you think and communicate your thoughts about software development. It's this point I'll defend below.

The example DHH gives seems like one I'd like to specifically call out. If you can't write a bubble sort there's some real problems. You're unable to take a few hints about an implementation that are obvious from the name. It'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't exactly recall the algorithm, but that'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:

    for (int i = 1; i  list[j+1])
          list.swap(j, j+1)

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.