Building on Marcin's response.
The Guerilla guide to interviewing (latest version is best!) is very useful.
It helped me a lot when I first had to evaluate technical staff for hiring few years ago during an expansion spurt (I was hiring electronics development and embedded programming, not just general purpose coders for enterprise software)
I'm not 100% sure of all his assertions - Don't really think that always having 6 people interview one person one after the other is a valuable way to spend 6 people's time when they also have project workload, but have to agree that "smart and gets things done" is pretty much the best summary of any good employee you will ever get, and if you keep those two indicators in mind, plus maybe a pinch of "technical culture" you'll be on your way to getting the technical side of things evaluated.
Also - there is nothing more true than this:
"Never say “Maybe, I can’t tell.” If you can’t tell, that means No
Hire. It’s really easier than you’d think. Can’t tell? Just say no! If
you are on the fence, that means No Hire. Never say, “Well, Hire, I
guess, but I’m a little bit concerned about…” That’s a No Hire as
well. Mechanically translate all the waffling to “no” and you’ll be
As someone who did once give the nod to a maybe that turned out bad (I was making excuses for bad aptitude test performance and bad explanations in the interview because they seemed confident - but now I know I shouldn't have) I can say that it's the sort of thing that causes a lot of damage and distress to a development team....
Apart from the info from Joel, you need to use whatever tools you have available to get your new team members without taking up all of your productive time.
I had a recruitment agent our company uses, who has basic maths and logic tests, and over a few different hiring sessions these turned out to be a great indicator for people that did well at technical interviews and at actual work afterwards. From what I've seen, you should expect any viable applicant to a technical job to score in the top 5% of the population for these things, even on a really bad day... The recruiter also did a psychological "DISC" analysis report which was always interesting to read, but I think I could live without that if I was paying the recruiting bill out of my own pocket....
For the programming side of my evaluations, I also used a couple of softball C questions, like described in that article. I'd consider them directed discussions rather than actual tests - It's not just that they can do it, but how fast they are and how confident, and the discussions you have along the way. For bonus points, mine were made of simplified parts from our existing code base so they also gave me a bit of a view into how their thinking process worked with our existing "code culture", and gave me a look at how they handled things that are important to us, like state machines.
Interestingly enough, I even tested a junior staff member who did great at the basic aptitude tests but with no real C experience by feeding him the "general knowledge C details" as needed for one of these tests and concentrating on his logic to explain the workings, and then add functionality. He turned out really good.