Giving Technical Interviews


Back when I worked at Tellme, I had the chance to give a few technical interviews. In retrospect, one of my mistakes was asking questions that were too hard. It’s tempting to ask a challenging question, particularly one that requires a “trick” to solve it. If the interviewee figures it out, then he must be good, right? 
In reality, he may have just heard the problem before. Furthermore, if someone fails to answer a question that is hard, you don’t learn very much. Good people can get hard interview questions wrong within the timeframe and format of an interview. Perhaps they don’t notice the trick required to figure out the question. 
On the other hand, if you ask a sufficiently easy question, it acts as a negative filter. If someone fails to answer it, then surely they don’t have the technical skill required. Fizzbuzz gives an extreme example of this idea.
The best type of question is one that is easy to answer, but harder to answer well. I was asked a question like this last week:
How do you remove the duplicates from an array of integers?
This is not a hard question. A naive O(n^2) solution doesn’t require much thought, but requires coding ability to get the details of an implementation right. An improved O(n*logn) solution requires knowledge of data structures, but is still not that challenging to find. (Sorting the array gives another “easy” n*logn solution; to avoid this, you can stipulate that the result should be in the same order as the original array, or that the numbers are streaming in.)
Any serious applicant should make appreciable progress on this question. A good applicant should be able to solve it completely within the time-frame of an interview. And this should be a much better filter than a harder question that may not correlate well to actual ability.