I can explain every detail about how a bit of software I did not write works if I study it long enough. I can even do a pretty good job of explaining why I wrote the software a certain way, even if I did not write it. I can make said software look quite beautiful, and give a rather impressive presentation about how it works. I'm sorry, but there's probably no way that you can tell that I did not write this particular software, unless you happen to know the software. Just because I can describe, in detail, how a bit of software works doesn't mean that I'm capable of writing it or something like it myself.

I pass over hundreds of resumes a month, after they've been filtered by HR. I've interviewed countless people over the past fifteen years. I've seen it all. People often embellish or outright lie. Many are not nearly as good as they think they are. Board problems are objective. They can't be faked, and unless the problems are known ahead of time, they can't be rehearsed.

Actually, if the CS board problem is done correctly, then error handling, software design, and planning can be measured. There are plenty of corner cases in most of these problems. That's where the real fun begins. Even something as simple as adding and removing items in a linked list or a binary tree leads to corner cases.

Everything else comes down to Q&A. That's where we get into probing questions about design, documentation, etc.

As for code samples, I'm not a big fan of code samples. You won't believe how many times I've seen people plagiarize source code in interviews. The only exception here is the take-home test. The only problem is that take-home problems have to be rotated out pretty quickly. They hit the forums within a week.

As someone who gives CS interview problems, I have to disagree with your assessment. The problems aren't designed to prove that you can implement a bubble sort. It's meant to be representative of the sort of typical hard problem you'll be faced with writing software. The reason why we choose CS problems is because they are properly bounded, they have a finite number of correct answers, and if you get off course while working them out on the board, we can better help you to get back on course. Furthermore, there are decades of research that have gone into these problems, so a naive board implementation leads to all sorts of prompts for interesting questions.

Most of my evaluation has nothing to do with whether you get the right answer or the wrong answer. It has to do with how you arrive at the answer, and how you respond to constructive criticism, or in a pair programming environment. I couldn't care less if you can write a bubble sort coming in; if you solve the problem quickly, I'll just substitute a different one that you can't solve quickly. It's the process by which you arrive at an answer that interests me, and CS problems are, by far, the easiest way to uncover this.