I think hiring programmers should really involve the developers they'll be working with. No trick questions or silly problems. Just have them sit with people from the team and talk about the stuff they'll be working on. If they get fired up and start spouting solutions to the types of problems offered, you very quickly see what kind of developer they are. If they're suggesting something you've already tried, that's a good sign. If they already know the pit falls you've encountered before you mention them, that's also a good sign.

What it comes down to is that the engineers are better suited to evaluate engineers. Obviously, you've got to have final say as leader of the company, but the engineers are your best asset here. This is why good VC's always have a luminarie in their back pocket to send out to evaluate tech before an investment. Even technically competent VC's would rather send an experienced database developer to look over a new DB company rather than rely on their now 15 year-old experience.