[davidw]

> If given a programming problem, don't stand/sit quietly while you work out the solution. Give the interviewer some insight to your thought processes.

I think most of us are much more naturally going to sit and quietly do our work, as we have done all our lives, unless you're asking us to talk you through what we're doing.

[Jim_Neath]

+1 for that.

I'm not in the habit of shouting out what's going through my mind as I'm working.

[gvb]

But this isn't work, and the answer isn't a program.

This is an interview, your "customer" is the interviewee, and the answer you are trying to impress on your "customer" is that you are smart, articulate, personable, etc. Even more important, can the candidate look at an obvious question (the quiz) and see the underlying real question (is this candidate outstanding?).

All the things that don't come through on a paper-and-ink resume.

P.S. I've worked with lots of engineers that answer the question that is asked, but never think about what is underlying the question - sometimes the question is wrong. That is the difference between "smart, and gets things done" http://www.joelonsoftware.com/articles/fog0000000073.html and "done, and gets things smart" http://steve-yegge.blogspot.com/2008/06/done-and-gets-things... (a GREAT rant).

[potatolicious]

More importantly I think, in "real work" you will often have to explain/justify your implementation and design decisions - which is also basically what you're doing in front of your interviewer.