Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough.
I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices.
I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at.
The alternative interview technique that I like to use when hiring engineers is to send them the questions I'm going to ask a few days before the interview. I ask difficult questions, but there's no surprise. I don't really care if they talk about them with other engineers beforehand...there will always be follow-up questions that I ask to get them to defend their solution that will uncover those that haven't understood the problem fully.
I was asked to come up with a recursive-like solution for puzzle like problem. I just froze during the interview. Later on kept thinking about it for couple of days and sure enough I was able to come up with three different solutions that used various techniques such as memoization and I felt really good about it.
I guess what I'm trying to say is it's really counterproductive to evaluate someone's abilities by subjecting them to time pressure.
"Boy you sure criticize those Nazis a lot for genocide, but you offer no _real_ solution." "Dude... stop criticizing those banks for their greediness when you have no solution". I realize these are rather hyperbolic examples, but you see where I'm getting at.
As for the OP, this does seems like really cool stuff, even if I don't really agree with "the interview" method myself because I don't do too well at them. I mean sure, there should be some on the spot questions to get sort of an outlook feel on the candidate, but that really isn't sufficient.
Why not give the the candidate a real world problem - maybe even related to something your company is trying to solve - and a few days to come up with a solution. I don't care if they also do some copy/paste from SO and other sources on the internet. That's why the interwebz is there in the first place. What would be more important in my view, is how the candidate is able to integrate all the information he finds - be it on the internet, books or his own head - and converge to a solution. And even if he doesn't come up with a working solution, you as an interviewer can now infer a lot more useful pieces of information than with a basic interview. You can ask questions like: 'why did you choose that library over the other ones?', 'why that programming language over the others', 'how did you come across the code on Stack Overflow; is it correct?', 'why that database and not that other one?', 'why is your solution single threaded and event based, rather than multi-threaded?', 'how would you further optimize that piece of code?' and so on.
I think this kind of conversation is something much more likely to happen day to day between the candidate and his coworkers if he does get the job.
You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone?
These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer.
But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.