Finding quality developers can be a challenge. Trying to comb through all the resumes and pick the right person based on a short conversation is not an easy task. The entire process is exhausting especially if your company uses a multi-phase approach. Here is how the hiring process works at most large companies:

• First the job gets posted internally for a set duration. This allows current employees to get first dibs.
• If the job is not filled internally then the position is externally.
• Resumes are received by the functional manager. Then a list of potential candidates are given a phone interview.
• People who "pass" the phone interviews will come on-site to interview with the staff. Typically the functional manager, an HR representative and one technical person will meet with the candidate. If you do well on these interviews then you get hired.

Recently, I have been the "technical guy" at the interview. Over time I have built up a standard set of questions that I used to interview a developer. Most importantly I always ask that the developer to bring a code sample to the interview. Anyway, here are the questions I ask:

1. What is your favorite programming language and why? My first question is always a warmup question just to get the candidate comfortable. Some people freeze up during interviews and I like to break the ice by asking an easy question first. This question is really aimed at getting them to open up a little bit and make them comfortable. The answer to this question can easily be steered into more advanced topics. If they can expand on the subject well than you can get an idea of how deep their knowledge about the subject matter is.
2. I am a business user with no programming knowledge. Please explain to me in simple terms what a bubble sort is... This question is designed to see how well them candidate can communicate technical knowledge. Although a bubble sort is somewhat simple it seems to stump a lot of people. If they do not know what a bubble sort is then I will ask them to explain how binary numbers work. If you can not answer either of these questions than you are in the wrong profession.
3. Do you write code in your spare time? Someone who has a passion for programming will almost always have written some code just for fun. If they are not doing any side projects at home then this could be a good indicator that they really do not have a passion for programming and they are only writing code because it pays the bills. Simply put, people who love programming are better programmers.
4. Explain object oriented programming and why it is important? You should hear buzzwords like inheritance and polymorphism as a response. It is good to follow up with a simple design session. Have them design a couple of simple classes that utilize inheritance or adhere to some type of interface. Tell them to use pseudocode if they get too concerned with syntax.
5. Tell me about the code sample you brought? You can learn a lot about someone from the code that they write. Putting it another way "Would you commission an artist to paint you a picture without seeing their portfolio first?" I tend to also treat this stage of the interview process as an informal code review. See how the candidate responds to constructive criticism and if they have good explanations for the way that they structure code.
6. What is MSIL and why is it important (.Net specific)? Anyone who knows anything about .NET should be able to answer this question.
7. Explain the lifecycle of an ASP.Net page (.Net specific)? I generally make the candidate expand on this topic so I can get a clear understanding if they understand topics like viewstate and postbacks.
8. Where are shared assemblies stored (.Net specific)? A .NET 101 question but I am still surprised to this day how many people get this question wrong. Make sure they can also explain the logic behind making a decision to use or not use the GAC.
9. How do you keep your skills up to date? Do they blog, go to conferences, user groups or read books to keep their skills sharp? People who are good programmers are always trying to learn new things.
10. What do you want to do in five years? Technical people want generally want to stay technical. Lousy programmers eventually become managers...LOL