Couldn't disagree more with the author. How many developers need to implement their own binary-tree? This is why code-bases become convoluted with six different implementations of standard data structures.
The author says that the candidate's thought process behind arriving at the solution provides insight into the candidate's skill.
There's no reason to implement your own binary tree, but knowing how to devise algorithms to accomplish a given task is a necessary competency.
Agreed. Why not use a realistic problem and setting?
I can usually tell that someone is unacceptably bad within a few days of working with them, so it makes sense to do those few days before hiring (if possible).
Trivial problems are a good filter, as long as you manage to maintain a non-stressful interview environment. Whiteboard coding is a good thing, because it shows that one really understands things, not just memorised keystrokes.
Doing about 80% of my work on a piece of paper, I cannot really comprehend all the moaning about whiteboard being "detached" from anything practical.
Assuming someone is a good programmer because of trivial examples like reversing a binary tree or, worse, writing a bubble sort is like asking someone you to use a wrench to prove that you're an architect.
I learned how to think recursively in college. I never learned how to reverse a binary tree.
I don't think that being able to describe an algorithm you haven't had to implement in more than decade (at least, that would be the case for me, college is starting to be a long time ago for me).
Honestly right now, without looking up the answer, I probably can't reverse a binary tree on a whiteboard. I could, however, do it by test driving a solution with a real computer (I haven't flexed those muscles in a long time, but test driving would help me dig into the recesses of my brain).
Which skill set is more useful for production quality software? I can say for sure that it's not white boarding.
Personally, I don't actually believe in truly "mindless", trial and error TDD, as oftentimes it will miss the forest for the trees.
Amusingly now, three days later, I'm certain I could do this nonsense on a whiteboard now, as thinking about it three days ago seems to have primed my subconscious to dig it up.
Furthermore, the business value of a programmer is rarely how she writes code in isolation. It's how she writes code on a team. I'd take a B-level programmer who is excellent at writing clean, readable, simple code over someone who is a savant at white-board problems.
That's a blanket statement. If we find one exception to this rule, then we can say that it's 100% false (since its truthfulness is binary -- it's either true or false).
To find one exception, we only need to find a single "good" piece of software whose author can't write 100% of the dependencies, including: (probably) C/C++ compilers, FS drivers, low-level network libraries, and the widely-used monster that is SSH.
Compilers & drivers aren't libraries. Low-level network libraries, using libuv as an example, have concurrency gotchas that require awareness on the part of the app developer. Using TCP as an example, think of the pain people go through over nagling.
Security software is the best example of something we use without understanding but it has gotchas; you need a nontrivial understanding of the internals to guard against sidechannel attacks.
BTW, I've used primality testers I don't understand and couldn't implement on my own. How might I be more effective in calling is_prime()?
Trees are the single most important data structure in computer science. Just
about everything you do in your programming career will be related to trees.
E.g., turn {"foo": {"bar": "moop"}} into {"foo-bar": "moop"}. This also requires writing accessor fns, but it might be worth it, depending.
One thing often forgotten with hashmaps is that they aren't actually O(1); they're O(k), where k is the length of the key, and often need to examine the entire key to derive a hashcode. This oftentimes makes them significantly slower than a binary search tree when the size of the key is large compared to the size of the container.
As always, measure before optimizing. YMMV.