We tend to have a two-stage interview. First, the phone interview weeds out people who obviously lack the skill set that we are seeking. As part of this, we have a snippet of code that is designed to be bad code that we send to the candidate and ask them to make suggestions on how to improve the code. The answers that they come back with for that one are quite interesting and revealing.
Once a candidate for a developer position reaches the in-house interview stage, it is (typically) a three-person interview. In no particular order, we have myself (the Senior Developer), my boss (the System Architect / Development manager, who is the actual hiring manager), and his boss (the CTO -- hey, we're still a small company, but I'm not sure how much longer the CTO will still be conducting interviews for positions that are now several steps in the managerial chain beneath him).
We tend to conduct interviews with behavior in mind: not "what have you been a part of" or "what events have happened to you," but "what have you done?" It's actually surprising how many people don't actually answer what their specific contributions to a group were, even when asked directly. Instead, they list the group's successes. That's nice, but we are not hiring the group. We need to know how you contributed to that group's success.
In the interviews, my manager tends to focus on trainability where I focus mostly on technical acumen. Typically I try to key my questions off their resume, asking more detailed questions about things that they say they have experience in but not neglecting other aspects (in case they forget/don't consider their experience worth mentioning).
Having had a few people in the past who had some downsides that were not detected during the interview process (that's the charitable way to put it), I have a few key technical questions that gauge different skill sets that a candidate might have. These I ask regardless of the resume, and they each tell me something different.
First, there is a question designed to indicate how well the candidate can actually read code. I find that code-writing exercises, like "please write a loop" or "write a function that reverses an array" are almost worthless in an in-house interview. My typical code-reading question not only gauges how quickly and efficiently they can read code, but also how well they understand how
Java works:
The question, of course, is what is printed? I look not only at their answer (I've only ever had one candidate get it right, by the way), but also at how well they can actually read through the code. I've found that many people are capable of writing code, but not actually that capable of reading and understanding existing code.
The other question is more off-the-wall, but it does show their analytical skills. It is a whiteboarding question, in which they go to the dry-erase board and think on their feet. The question: draw an object-model of a
chicken.
I don't care if they use proper UML notation or if they just put up their ideas randomly. I'm basically looking for how well they understand their is-a and has-a relationships (and what methods such an object might have) and can break things apart. That is, a chicken is a bird which is an animal. A chicken has a beak and wings and feet. A chicken can lay eggs. Sometimes a candidate does only one or the other of is-a and has-a, but they usually always include what methods a chicken has.
(On a related note, this can also be the most entertaining part of the interview, at least afterwards. I've had a candidate design the lifecycle of
chickens without actually describing them. That design included farm objects and cages and methods to calculate the yeild of eggs and the next generation of chickens -- as if hcicken farming were a hobby of the candidate! Another gave their chicken hands instead of wings -- I guess that's where chicken fingers come from).
Anyway, once we finish, we compare notes. We try to come to some consensus as to the relative skills and suitability of the candidates, with the hiring manager making the final decision (of course).
I hope that this helps.
, I found it very entertaining.
