Of course, most of us around here have been on both sides of “that desk,” and so we can attest that both sides are no-fun.   One of the biggest problems that I see companies rather-consistently making, is that they search for (say ...) “Perl experience,” instead of, “experience!”   Hence, they write “difficult” tests, about a particular language or tool, give it to you examination-style, and demand that you must provide an answer that they can subsequently “grade.”

I take a different approach, and would recommend it:

1. “First, tell me about a program that you have written for another employer ... it doesn’t matter which language was used.   Tell me what this program does, and what role you played in it.”   Now, listen patiently, maintaining eye-contact if s/he maintains eye-contact with you, and looking slightly to one side if s/he doesn’t.   (Don’t expect a computer programmer ever to make eye-contact with you.)   How quickly and how effectively does the candidate communicate that answer to you?   By what method(s) do they attempt to do it?   Are those methods effective?
2. Next, briefly and generally describe a problem that your team is actually facing, give a high-level explanation of it, and ask the candidate what s/he would suggest and what sort of role s/he might be comfortable with, in working with such a project.   Take a slightly more active role, trying to steer it into a high-level technical discussion, avoiding unnecessary mention of particular Perl packages.   How well does the candidate engage in that discussion?

And the proper thing to do, if you are on the other side of the desk, is self-evident.

Yes, I’m most interested in “soft skills.”   To me, human communication, and congeniality in the face of pressure, is far more important than one’s technical command of this-or-that language or tool.   And, as I said, years of actual experience.   If you don’t yet know Language-X, then I can teach you that (or, you can pick it up yourself, over the weekend).   But the fundamental skill that is needed is the ability to talk to people and to develop and build a technical framework, and/or to look at existing source code, divine what it actually does, and develop a change which neither breaks it nor re-writes it.   “I’m not running a school, so I’m not going to give you a test.”   But you should, by now, have a long list of professional references.

And, as a candidate, you need to swiftly make the decision, “Do I actually want to work here?”   Almost everyone works in a cube-farm, of course, but there are pleasant ones and unpleasant ones.   Almost every team uses some kind of methodology to their madness, but methodologies preached from a podium only get in the way.   And so on.   “Trust your gut,” don’t burn any bridges, but also don’t put yourself in Hell.   (You’ve already been there enough times, aye?)   ;-)