> A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and

> A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too. Really? You could easily fake that, have a friend who still works somewhere say anything. > Ask them to bring in an interesting example of their own code to the interview. That's great if you're willing to weed out people who only code at work. > Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs. That's what you can do without their own code, but it fails to prove they really wrote it.