If you are involved in the interviewing and hiring of software developers, it's vital that you have a good set of technical interview questions to aid you in the process. In this article I'm not going to give you a list of questions. Several smarter, more resourceful people have already done that. Instead I'm going to describe five attributes that make a question great!
You should be familiar with the question you are about to ask. You'll want to know the best solution(s), the second best solution, other approaches that work but aren't optimal, dead ends, space/time complexity, etc. This knowledge will allow you to focus your full attention on evaluating the candidate (rather than scrambling to figure out if their solution works).
When the interviewer lacks this understanding, a few bad things can happen. Sometimes they'll claim that a solution doesn't work, when in reality it does. Other times they'll prematurely steer the candidate away from a line of thinking because it doesn't line up with the only answer they know. Or even worse, they'll say a solution works when it really doesn't. All of these are usually preceded by a lot of umming and ahhing as the interviewer tries to decide if it works. You're going to look really bad in the eyes of the candidate.
Another advantage of asking familiar questions is that you will begin to develop a sense for how hard the particular problem is. You'll gain a sense for how people generally navigate the problem space and arrive at a solution. This experience enables you to compare performance across candidates.
We are not just looking for "The Perfect Solution", but rather how they got there, how many hints they needed and how long it took. A mediocre solution with good discussion and clear understanding is better than "The Perfect Solution" without. It's very difficult to judge any of this with new questions.
Give them an opportunity to show you how much they know (or don't), by asking several different types of questions. Ask questions with enough depth and breadth to get comprehensive tour of their abilities.
The areas you'll want to cover vary, but some common ones are Coding, Data Structures, Algorithms, Object Oriented Design, Math, Logic, Architecture and Web Technologies.
A good question should take between 10 and 20 minutes to solve. Anything shorter is too easy. Longer questions make it hard to cover enough ground during the short time you have.
Some people complain that interview questions feel so contrived and fake. "You should be asking real world problems" they say. If you can fit real world question into 10-20 minutes then great, go for it. Unfortunately most real world problems require too much setup and background explanation. It's easier to have them manipulate a list of integers, than a list of SavedWidgetFilters.
The question should be easy to explain. A confusing question will often be misunderstood and can waste valuable time. It should take less than 45 seconds to explain the question. Also consider having the questions typed up beforehand.
Stay away from questions that depend upon a clever insight or non-obvious tricks. Remember that the candidate is under a lot of pressure during the interview. It's better to focus on questions that allow the candidate to use common techniques like they would on the job.
The questions you ask are only part of what makes up a good interview, but they are an important part. Take the time to build up an arsenal of good questions and make sure you're familiar with them.
