I do tests for prospective candidates, but my approach is slightly different. After the interview I email them a small unfinished program. I then give them a

I do tests for prospective candidates, but my approach is slightly different. After the interview I email them a small unfinished program. I then give them a set of instructions on what I would like them to do to finish it off, and they can then do it at home on their own dev setup; with the internet and any other resource they would normally use for development. I give a coding style guide, and in the areas where some specific technique is required I make that explicit. The app has a few bugs in it, and some of the techniques asked for are slightly leftfield. I instruct them that if at any point they have any questions then feel free to email me - and they won't be marked down for asking questions. In fact I mark candidates up if they ask questions. The task shouldn't take more than 30-45 mins for a decent coder. I find this to be a really valuable approach to seeing how a coder works. It shows how they work with others' code, it shows they can follow instruction, it shows they can communicate when unsure rather than hiding away and it gives a good guide to their style of coding. It's a far less confrontational approach, and gives the candidate the best chance of showing what they can do. In the interview I tend to be much more interested in the person, because I'd rather have a coder who is slightly less capable that I can train, than a coder who is amazing at everything but won't fit in. I'll still discuss past projects and dig deeper where necessary, but I like to find out how they influenced the outcomes of projects rather than get too deep on algorithms and the like. So far it's worked very well :)