|
Over the last year, I've spent quite some time interviewing engineers for our Berlin-based startup. Having sat at both sides of the table many times got me thinking about how to best conduct such an interview. Approaches vary, however, I think a few things are common to all of them.
In terms of "what" I interview for intelligence, persistence, and cultural fit. In terms of "how" you can apply various techniques, from interviewing two-on-one (rather than one-on-one) to scheduling as many interviews in a day as possible to see how the interviewee's performance holds up over time. (Microsoft, at one time, after a full day of interviews was still banging away at me on a Friday night at 7pm---so much for those who believe M$ has become lazy in recent years.)
Specifically, for engineers, I think you need to interview for technical competence next to the general criteria. This is primarily because raw intelligence is not a sufficient condition for getting up to speed in time for technical work. In particular, just throwing riddles and brainteasers at an interviewee doesn't cut it, in my opinion. Here, then, I'll focus on interviewing for technical excellence, in particular for software engineers.
I interview both for breadth of capabilities as well as depth of capabilities. I believe that the following four main categories cover pretty much what needs to be talked about:
- Math, binary logic, etc.
- Data structures and algorithms
- Object-oriented design
- Architecture and performance
Basically, I work my way bottom up. An example question from category 1 is: "What value is '(234 and 79) xor 189'?" You may feel embarrassed to ask such a simple question, but then, it should cost you only a or two minute to ask and get an answer. And if the person doesn't know the answer, you just learned that maybe his or her education wasn't as thorough as you had hoped.
Category 2 questions are somewhat more elaborate educational test questions. An example is: "What is the space/time complexity of searching over a map of bags?" Or: "How would you implement managing a collection of string sets of some property?" Such questions should be answerable by anyone with a B.S. in computer science. It doesn't tell you more than that, though, as these are pretty basic applied learning questions. So I would ask a few questions, but if the interviewee nails them, I'd move on.
Category 3 questions are more interesting then. An example is: "You are an insurance company. How would you model your retail customer regarding their patient relationships with doctors?" Basically, you are trying to learn whether some person has a grasp of real-world modeling issues and can bring in prior experience without having to know too much about the application domain. (Regarding the example question, I would expect the interviewee to talk about decorators, dynamic object loading, and state integration.) If you want it simpler (and closer to category 2) you can always use the infamous underspecified Singleton Counter class.
Category 4 questions finally are open-ended and require experience as well as the ability to draw on multiple forms of experiences and knowledge. An example question is: "You run a server with multiple clients. Each client can inject code into your server. How do you prevent any such injected code from bringing down your server?" These questions are the toughest ones. Like category 3 question, they don't necessarily have one right answer. But you can see how the interviewee is struggling with the question and learn from that about his or her abilities to be creative, explore alternatives, evaluation options, and draw conclusions.
In my opinion, an interview process should proceed from category 1 to 4 in accordance with the apparent abilities of the interviewee to answer these questions. Typical mistakes I've seen being made is to get stuck in one category, say, because you like category 2 questions so much. Another mistake is to throw only your current problems at the interviewee, so you are typically asking only questions from a specific category, and you are missing out on information about the other categories.
Regarding depth on any of these questions, you can and in my opinion should take your time. If you feel the person is winging it, sit them down in front of a terminal and have them solve a real programming problem of the current category. The cost of bad hiring is prohibitive, and you want them to be real. Putting code on a white board goes only so far. Have some real programming problems ready for any of these categories that can be solved in a reasonable amount of time. (Yes, I think this is possible; I've seen it happen and done well.)
So much for interviewing for technical capabilities. There is more to be said, so maybe I'll amend this blog entry in the future. Stay tuned! And subscribe to this site's RSS feed.
See also hiring and collective intelligence.
|