After reading the article, I feel like a code test and discussion and or whiteboard would have filtered the type of developer they mentioned who is a net negative on the code base.
I don't think there's a magic interview style that prevents this problem. Corrective action and fast firing if necessary have worked for me. And whatever you do, don't impose onerous procedures on all of your devs because one of them screws up on a regular basis!
This is a really important point. Creating processes for the lowest common denominator just stifles every other developer.
He had an appearance of technical skill, was very well spoken, knew all the interview questions and answers, but had really bad judgment and somewhat poor logic when he had to come up with novel solutions. On the contrary, I taught myself and didn't have the CS background to do well in purely technical interviews. But I was given the practical challenge and crushed it. I knew what I needed to know for my job. Of course I had a lot to learn (and still do), but I was productive from the start, or so I have been told.
I guess there is nothing wrong with whiteboard tests, but I think a practical coding challenge where the applicant makes part of an application is much more valuable. You can see that they have basic coding ability, but also how they organize code and break down larger problems. Can they get the big picture right while making clean, maintainable code?
I was good at code tests straight out of university (when I practiced that sort of thing). 13 years later I am a far better software developer, keeping things simple but functional. I am a lot worse at code tests now, as I hardly ever need to write that type of code. I am able to design things in a way that doesn't usually need complex code to achieve the required functionality.
This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.