Ask them for a solution to a problem. Tell them you want the solution using best practices and with all of the bells and whistles. They should be able to do thi

Ask them for a solution to a problem. Tell them you want the solution using best practices and with all of the bells and whistles. They should be able to do this. Then tell them the optimize the solution for: - development time - execution time - memory constraints A good programmer should be able to respond to changing needs. They should be able to see the best solution for the current situation. They know what technical debt they are incurring and should identify it in their solution. Also, if this is a small team then personality should play a large part in your decision. One person can really ruin a productive team. Does the person respond to your feedback well? Where do they show cracks in their facade? Do they explain themselves clearly? Can they think in the abstract or do they always speak in terms of their domain? Will you be able to give them high level directives or will you have to talk them through line level code? Can they do things the way you do things or do they have to change the world when they are out of their comfort zone? Do they feel a desire to throw code out when they don't understand it or can they work with existing code? Do they use phrases like "it's broken" or other catch all phrases that indicate they don't understand something and are unwilling to learn it? Do they ask for clarification or do they make assumptions and quietly go down the wrong path? When they do ask for clarification, is it at a level consistent with their title and experience? I can go on, but I might save it for a blog post. I have learned a lot from having to staff and lead a team and the above have been some of the points that have distinguished the producers from the consumers. Cheers and choose wisely.