Part of my job at many clients has been interviewing new candidates. It’s a thankless job, that if not done well, can cost you and your client dearly. All of us have had the torturous interviews with Google searching morons that ask you questions like how is a hash table implemented, to which I respond “I don’t care if it works.”

There are two different types of interview questions, the specific and the general. Questions like “What color do you get when you add blue and yellow together” will only tell you they know how to make green. A better question is “How do you use a color wheel.” Can you see the difference?

When I interview a candidate for a position, I use a set of questions that dips or tunnels into the specifics on their knowledge and background. Here is an example:

How many lines in an Asp.Net code behind file is too many?

If they answer with something reasonable like 200 lines, then I would move on. If not, then you might have other questions.

How would you break up a code behind file to be smaller?

Again, hopefully, they say something about user controls and breaking up the functionality on the page and not move the hard coded injection flawed SQL queries from the code behind. Then you can dig a little deeper and ask something harder like:

How do you communicate from one user control to another or to the host page?

If they answer this last question correctly, you know that they know what’s going on in Asp.Net and not that they have memorized the page lifecycle. Did you notice who would have to do most of the talking? That’s right, the candidate. You can pick up a lot from these conversations.

Here are a few more conversation starters

• How can you throttle WCF service calls from a specific client?
• What’s your take on ORM’s good and bad?
• What blogs or books have you read in the last three months?
• What would you like to learn next?
• How can you share data from one website to the other?