You will only be able to get optimum benefit from a given person if you have optimum work processes; if your processes suck, and/or the person in question isn't able to work with them, then it dosn't matter how good they are -- you won't realise the full benefit of their skills.

Unless the role specifically needs a savant, you're probably better off with someone who is technically adequate (say, good C and shell, but no perl experience) and excellent on the process/interpersonal side (organised, thorough, quick learner, teamplayer, etc), than with someone who has the technical skills of Merlyn, but the personality of Norman Bates.

Take care not to focus solely on hiring the people who have the particular skills and knowledges that you currently need, be aware of the people who have the talents that you will always need -- the ability to learn quickly, work well with others, be thorough, disciplined and organised -- these are the people who will always have, or be able to quickly develop, the skills you currently need.

That said, there remains obvious and definate merit in technical testing, personally I favour the "what does this code do" problems to the "write code to do this" ones, likewise I would advocate generalised, pseudo-code ones to language specific tests. Any tests should be designed and evaluated by the people most familiar with the specific job that the candidate is being considered for.