"What operating systems have you used?" I asked a help desk applicant years ago. She pulled a paper from her purse and, referring to it frequently, recited a respectably long list. I literally didn't know what to ask her next.
I've run across quite a few interviewing techniques over the years. I know of one company that surrounds the applicant with interviewers, creating an inquisitorial atmosphere, to find out how the applicant responds under pressure. I'm pretty sure I'd fail this one - my response to this kind of pressure would be intense irritation.
Then there are the companies that use a battery of aptitude, psychological, and skills-inventory tests, based on the theory that, although you can fool an interviewer, you can't fool a psychologist who's never met you.
There's the old standby, "What's the worst mistake you ever made on the job?" My favourite answer: "I once chose an inferior grade of concrete on a construction project. Fortunately, the building collapsed while under construction, so all we lost were a few welders."
And of course, there's the entrepreneur's approach: relying on gut instinct. This technique is remarkably effective - it infallibly selects the applicant with the best hair and handshake.
Overall, the two most effective techniques I know of are to have the applicant describe past successes in detail and to "do the job in the interview" - a concept I learned from Nick Corcodilos of Ask the Headhunter fame (www.asktheheadhunter.com). By asking about past successes you find out whether the applicant is in the habit of succeeding and what the applicant considers success to be. By having the applicant do the job in the interview - explaining a current situation and asking what he or she would do about it - you should get a good idea of how the applicant would do the job.
I'm adding a third technique to my arsenal. I discovered it by accident, when I interviewed that help desk applicant who had such amazing operating system expertise, and recently rediscovered it while interviewing a vendor with which we were thinking of becoming partners on a project: ask a really easy question.
I'm not talking about questions with right or wrong answers, especially not questions in which "right" means agreeing with the interviewer. I'm talking about questions that reveal if the applicant - or the vendor, if that's who you're interviewing - understands the subject area based on real-world experience.
If you're interviewing a vendor, here's an easy question: "What are the key things we need to do when we implement your project so that we get the business results we want?" Any vendor worth buying from should be expecting this question. You should get a crisp, well-thought-out, believable answer.
If you hear a rambling discourse that meanders all over the conceptual landscape or a too brief, uncomfortable disclaimer coupled with a squirming look of discomfort, you can be confident you're talking to the wrong company.
How about a systems analyst? "What's the difference between building a new application and implementing a package?"
Those who know the business will speak comfortably and knowledgeably about a long list of differences between these two processes. The ones you don't want will say, "It's all pretty much the same: you figure out your requirements, come up with a solution, and implement it."
By itself, the easy question technique won't guarantee you make good hires. What it can do is tell you, in no more than five minutes, whether you're wasting your time.