How to interview, 101.
Update: More rules being added in the comments, I have added rules 6 and 7 this morning after sleeping on this one :)
I was talking the other night with a friend about their interview experinces and in particular the how the interviewer gave the interview. I have seen a tons of interview prep posts (which I might do all the same) and not a lot on how interviewers go about it (as most seem to think that they do what ever they please, not so).
Rule .1, Don't behave like prat.
The interview is to assess the candidate against the needs of your company, your team and the role within it. Remember that you are likely to be the first person the candidate will see and as such you represent your company and your team. So lets get something stright, no one likes a prat and if you treat the interview as "power trip 101" you won't be hiring any time and it reflects badly on your company and your team. The net result is that rather than hire to solve your staffing problem you have fields of p***ed off candidate's, telling anyone within ear shot how much you suck.
Don't use the interview to boost your ego or be a smart ass, no one likes either and it achieves nothing. The candidiate will be nervous and that will reflect as either someone being quiet or loud, the key skill is put them at ease, make sure they are comfy and relaxing so you assess them as close to their true self as possible. Do start slowly and build up, do wait for an answer (pauses can useful if you think they have something else to add but don't over do it) and don't interupt if a candidate is still answering). You want the candidate to be free thinking and flowing with their answers, nerves, frustration and plain anger (at your behaviour) achieves nothing.
Rule .2, Do your home work
You expect candidates to do there home work on your business so do the right thing and do your home work on them. You should have a clear idea of what education, skills and experience your after, go through the CV with a fine comb. The candidates that match your requirements are the ones you choose first, any that are grey but peak your interest go next. Look for examples of project work and problem solving and look for examples of candidates that go further, do they take part in open source, run a user group, speak at confs etc. Look them up on the internet, have they written articles, books, do they blog and if so what subjects do they favour. All these things help you see the candidate beyond the CV and will help you draw discussion points for the interview.
Rule 3, Do ask for code
I am not a fan of whiteboard coding at interviews, do we write code in the real world on a white board, I think not. However code samples are a great discussion point and if you create a code sample for them to create before the interview it gives you a chance to see how they solve problems and more to draw questions for the interview. A few things to remember here, create a spec even if its a use story and ensure you map out the minium requirements of what you want (e.g. a command line and not bell and whistles GUI etc).
Unless you give code standards don't expect them, even if you ask for Pascal notation it gives the candidate an idea. Don't expect tests unless you ask for them, should the candidate have created a test suite then make sure that counts in the interview (ask them why they created a test suite and if you asked for them what the testing aims were). Don't be tempted to use the code sample to create some over complex example, it will take too long to get through. Instead look at key areas where the candidate could possibly improve, ensure that candidate knows you may ask these questions so they have time to think about it and you can draw it back to any experince they may have.
Rule 4, Take them on a walk about.
Show them your work place and introduce them to your team. Afterwards you can judge reaction from your team about their inital impressions, don't draw too heavily on these however as your team is a bunch of strangers to the candidate and vice versa. Do use it as a tool to see if the candidate asks questions and understands some of your process's.
Rule 5, don't be late.
Can't be helped sometimes but leaving a candiate to sweat for a while after arrivial is a favoured technique to drive up the candidates nerves. If you can't start the interview at the allocated time, make sure the candidate is offered a drink and understands you can't start at the allocated time.
Rule 6, don't ask stupid questions.
Some interview questions (manhole covers and blue sweets for example) are designed to help an interviewer look for how a candidiate solves problems, however its nothing that questions about experince from the CV and rule 3 won't let you understand in a clearer fashion. You should also keep the questions relevant, asking about tools or technologies that the person used 12 months ago is a memory test and not a test of skills or attuide. If you want to understand what the candidiate did 12 months ago then ask them how they used the technology, what problems they faced and how they over came them. Not questions that ask on the webservice project in June 2001 what the 12th line of the SOAP packet looked like.
I agree with Derick (in the comments) that making the candidate feel foolish is as pointless as it gets. If the candidate does'nt know the answer then don't make a point out of it, rephrase the question or relate it back to experience or the code sample. Don't be tempted to ask a ton of technical questions that have no referance unless your running a test and not an interview, which brings me to rule 7.
Rule 7, it's an interview not a test.
If your testing the candidiate then let them know before hand, don't spring a quick 20 questions on C# and expect them to do well. If you want to test what a candidiate knows then should really use rule 3 for that and formulate questions that relate directly back to something a point of referance that you both have.