Paul Brower wrote:

Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.

As a former hiring manager I'd have to agree that writing code is often wasted time. My favorite approach (and hiring is as individual a skill as programming!) is to ask them to solve a common problem, such as how did they get to the interview, how do they make breakfast, etc. The answers to these questions will tell you a LOT about the person as both a programmer and a problem solver. For example, one candidate who specialized in embedded systems made use of timers to kick off processes, another candidate who was very UI oriented took the most non-linear approach I've ever seen, and even amongst "standard issue" programmers the answers were NEVER the same. I wish I had kept all the flow charts and pseudo-code that resulted from these questions! If the candidate got through that phase of the interview I usually asked them to write part of the exercise in their favorite language. A deep understanding of one language usually meant that they could pick up whatever languages we were using. Over the last couple of years that I was involved in hiring programmers I discovered that more than half the candidates had code in some open source project. If that was the case I knew I didn't really need to look at it, but I usually did anyway! In my experience (your mileage may vary) the programmers who could create a reasonable flow chart or pseudo-code outline worked out well. Of course I'll never really know how well the ones that could not would have faired... Bill