When I'm involved in interviewing someone, one of the interviews will be cookie-cutter. I've seen with my own eyes applicants who had stellar resumes, had great conversations with everyone they talked to... and could not pass a Cookie-Cutter Technical Interview.
You may think that it's insulting to have to pass a Cookie-Cutter Technical Interview, but we are not (generally) a Professional group - we don't have a Bar that you have to pass to be considered a professional programmer.
When I give something that looked like a Cookie-Cutter Technical Interview, what I'm really assessing is, "How much of my time will I have to spend explaining to this person how to solve programming challenges they'll actually see in the code they'll be working on, and how hard will it be to have that conversation with them."
The absolute best candidates were the ones who understood why I gave them the Cookie-Cutter Technical Interview, and related to me their own frustrations with similar oddities in programming... I concluded that they knew how to dig in to programming problems, and solve them on their own.
The next best candidates, who I loved to recommend to hire, were the ones who didn't know the answer to my questions (which were purposefully challenging), but who had a great dialog with me. I would encourage them to ask questions, to think out loud, etc. I know this is very, very hard to do in an interview, and I tried as hard as I could to be encouraging, and patient, and give hints when they were needed. And if they responded by asking good questions, stating their assumptions, verbalizing what it was that was difficult for them... I concluded that they would be good at identifying when they were over their head, which I hoped meant they would know when to ask for help, and I could also assess whether they'd be able to explain their problem succinctly.
Let me circle back with an anecdote: we had a candidate who looked great on paper, spoke well in all of his other interviews, had lead impressive teams at competitors, and who couldn't solve FizzBuzz. Hiring someone like this is incredibly expensive. Spending one hour of time with a candidate to make sure they can... program... is well worth the time.
And I'm sorry, but it's a Buyer's Market. People trying to Sell themselves as good candidates are going to have to put up with one hour of demeaning technical questions. Hopefully they'll turn that hour into a fun discussion about how programming is challenging, and relating their own stories of the oddities of the languages and libraries they use, and why they have certain preferences, etc. - a whole meta level above why ++i is different from i++, and how it's burned them in the past when someone didn't know the difference, etc.
You say "Let Me Code, Dammit," but most of your job will be READING code that other people write. I know what the code looks like here, and you don't. If I show you the warts, I can tell how you'll react to them. Do you call ugly code "ugly"?
http://www.osnews.com/story/19266/WTFs_m
Do you know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result?
Do you cringe when you see a %s with an int in the param list? Do you tell me that printf functions are inherently unsafe? How do you recommend making them safer?
If you code C++, do you know Boost?
Can you spot a new without a delete? Will you tell me to use shared_ptr or auto-ptr, or just use the stack?
Typing code is generally having good habits, using safe but powerful libraries and language constructs the right way. But maintaining code is a bit of an art. If you don't agree about what's "ugly" and why, you're probably going to push the body of code in a direction that I call unmaintainable.
And there are different strategies in how to make code more maintainable over time, but within one company, we should probably all be pushing roughly in the same direction.
"Let Me Code, Damnit" doesn't help me assess that as well as something that looks - at first blush - like a Cooke-Cutter Technical Interview does.