Round one includes a surprisingly simple "prove you can code in Perl and C" exercise, at a very nice, wall-to-wall whiteboard. Round two, several days later, is in the same room. The code on the whiteboard (for the same exercise) is different. Glancing at it during the course of the interview, I spot one outright bug, and then notice that whoever wrote the code didn't understand autovivification. And they didn't anchor a regex.
What would you do in this situation? Would you mention it to the interviewer? Why (or why not)?
So, I say, if you left them with any doubt about your coding abilities, point out the error, it will strengthen your position and weaken whoever wrote the code. If your skills are not in doubt it's perhaps a little tougher call, but I probably would anyway, maybe it is their way of a test.
A lot of the things I read about interviews stress being able to give the interviewer the impression that if you started today you could solve some problem they have today. I love it when they give you real world examples, maybe a problem they are currently trying to solve, and I'm able to give them some sort of solution. It proves that you won't need a couple weeks "ramp up" time to get going.
That said, it would also depend on the mood of the interview, not all things are appropriate in all situations.
I was shown production code in my interview. I did a quick scan and started asking questions as to why certain "standard coding practices" were not used. I believe that by pointing these things out, I earned some added "brownie points".
One warning, be prepared to fix whatever code mistakes you point out.
