After many years (coming up on 20 now) of interviewing candidates and being interviewed, I've found that programming tests are not indicative at all of candidate success in the job. The only reason to use them is a quick weed-out of resumes, before someone takes time out of their day to do a phone chat. Even then, only for very green/junior candidates.

My absolute favorite thing to do is go over the candidate's work history (or classes/personal projects if a recent grad):

* What project did they enjoy the most?

* What did they work on specifically?

* What trade-offs did they make?

* What were the major risks early on?

* How were those risks mitigated?

* Were there any unmet goals?

* What would they change in hindsight after seeing the project through to completion?

* What parts of the project were the most frustrating (non-technical answers here are great, like frustrations with deadlines, other team members, management, constantly changing goals)?

* What did they walk away having learned?

* How have they applied what they learned to future companies/projects?

It takes a bit longer, but it's so worth it. If you get a good programmer talking about a project they are proud of, you can end up talking for 30-60 minutes easy about every detail, have fun doing it, and learn a lot about them: how they think, how they work, how they work with others, how they work under pressure/deadlines, do they communicate well about problems, whether they'll be a good fit culturally, etc.