I realize there have been lots of discussions about this type of thing and they often devolve into dogma around whether you ask the "100 logical pirates" type of questions or whether you get them to write "fizz buzz".
I'm interested in what techniques and questions have been effective for you when interviewing potential developers for jobs.
One technique per answer so we can vote on them, please.
Besides real technical questions, and typically at the end of the interview I try to get a grasp of their level of interest in the industry and it's culture with questions like:
Have you seen anything recently programming-related that you found interesting and would like to recommend to other fellow programmers? A new language, tool, platform, technique, website?
Can you name any well known person in our industry whose work you like or find inspiring and why? (developer, web site founder, author, speaker, etc)
What are you reading now or what was the last software related book you read?
What programming related sites do you frequent?
Although failing to answer these questions at all (sadly it happens very frequently) does not mean a 'no-hire' to me, they say a lot about the way a person approaches the software development profession.
Make them write code, real code.
The interviewer may let you pick the programming language you are most comfortable with, be it C++, Java, C# or whatever and ask you to solve a simple problem, e.g. doing some work with a string or a doubly linked list or whatever. If you have trouble using your best language solving a simple problem then there is a problem. Please see Steve Yegge's blog post and especially the section "Mental Prep".
Have several people from your team interview them independently. Share your thoughts after, don't talk in between before interviewing them. Talking in between will sway your judgement and you won't have independent assesements.
For the technical people interviewing them make them write code. For non technical, don't try to ask things you aren't experienced with. Make sure you have at least some technical people interviewing though.
Interviews should not be conducted only by managers, it should be extremely important to every worker who they will work with in the future.
I like to have an interviewee explain their previous projects and what they did. From this answer I can have followup questions: why they did things a certain way, how did they solve a particular problem if they mentioned one, but most importantly what was the purpose of the project and what business problem this solved.
I do this to see if they can articulate in a way that makes me understand what they were doing, and see if they understood what they were doing as well.
It's surprising that the last question about the purpose of the project and the business problem solved that trips a lot of people up. They have no idea WHY the project they were working on was being done at all. If you don't know why your project exists in the first place, it makes me wonder if you are contributing solutions, or just doing as you are told.
(Figured I throw this one in there, since all the other answers tend to be technical. I want people that know why they are solving the problems they are solving too, otherwise, they tend to solve the wrong problems that the end user doesn't care about :)
Ask their take on an important architectural decision
For example. Here is program x that runs y number of subtasks concurrently. Which would you choose, a multi-process or threading structure.
What are the benefits/disadvantages of both. How well would they work and how could they be used to leverage a multi-core, multi-processor platform, what is your personal preference? Personal biases can aid in identifying whether they've ever had to actually apply the knowledge and give them a jump point to share their experiences?
There are tons of questions an interviewer could come up with like these:
Most of these topics are the types that involve an intimate knowledge of how/why a computer system works the way it does. They all are issues/solutions to problems that have no definite answer so they give a sense of how well that person is able to adapt or overcome the challenges at hand. Not the type of concepts that can be easily picked up without some actual hands on experience.
Note: Having the applicant write some pesudo code is a must too but that answer is already taken.
Just give them some basic code to do on whiteboard - e.g. linked list implementation, sorting or something similar.
You can judge how comfortable are they with their language without help of compiler and you can judge their thought process (especially if they never implemented such thing - most of "new" programmers never did).
Have a conversation, let it drift and meander along the technical and professional route and look for insightful or stupid comments along the way. This gets you 3/4 of what you need from an interview, an assessment of: people skills and personality, general intelligence, and a rough assessment of technical skills.
Use your interview "questions" as topic starters and for keeping the conversation corralled to technical topics - you may need to reset the conversation from time to time (such as doing a coding exercise) to adequately probe areas of concern/interest.
The real trick to this technique is to make sure they do all the talking, otherwise you run the risk of a favorable evaluation because they made you feel smart by listening to/agreeing with everything you said.
