>> Somebody who can intelligently discuss technology
>> Somebody who knows what they don't know
I believe in these principles especially. Most of my interview questions are vague (and I tell the candidate this up-front, and explain why). For instance, I'll ask them to explain how they would debug a very slow cluster, or to explain everything happens between me hitting the keys 'google.com' to me viewing the web page. This gives them a huge range of topics to cover in as much detail as they want. If they know a lot about Linux administration, or how hardware interfaces with the OS, or a lot about network protocols, they have a chance to show it off. I'll drill deeper into wherever they take the conversation, and a person scores major points with me if I drill down far enough that they get lost and say "I don't know, but my guess would be... and I would confirm that by...". I've found it to work exceptionally well.
Oh god, a question like the Google one would have me not knowing what to say... I mean, to give a reasonably complete answer would take hours and hours! What do you do if someone really goes into detail and can't even get to the part where the packet leaves the local network in a practical amount of time? Is that viewed as inappropriate overkill or a poor understanding of the question?
I wouldn't fault anyone for being able to go into so much breadth and depth that we ran out of time. I would suggest they just dive into the part they think if most interesting, or the part most relevant to the position. When we're out of time, we're out of time, but the point is just to stimulate enough technical conversation for me to evaluate the candidates knowledge, passion, communication skills, strengths, interests, etc.
edit: For instance, I actually got this question asked to me in an interview and adopted the practice several years later. It was scheduled for an hour, they asked me this immediately, and I was talking for most of the hour. I got through the whole process but didn't go into as much detail as I could've along the way. Several times I was stopped and asked to clarify some details, some of which I didn't know. That was that, and the interviewer just said "very good" and left. Looking back, I think he was doing the exact same thing I do now - giving me the freedom to show off what I knew, seeing if I would be honest when I reached my limit, and probing a bit to see if I could communicate about interesting problems.
I think you're allowed to ask the interviewer how detailed they want to be. I could spend an hour explaining how keyboard drivers work, if you want, or we can just assume that's a solved problem and talk about TCP, DNS, and SSL.
I believe in these principles especially. Most of my interview questions are vague (and I tell the candidate this up-front, and explain why). For instance, I'll ask them to explain how they would debug a very slow cluster, or to explain everything happens between me hitting the keys 'google.com' to me viewing the web page. This gives them a huge range of topics to cover in as much detail as they want. If they know a lot about Linux administration, or how hardware interfaces with the OS, or a lot about network protocols, they have a chance to show it off. I'll drill deeper into wherever they take the conversation, and a person scores major points with me if I drill down far enough that they get lost and say "I don't know, but my guess would be... and I would confirm that by...". I've found it to work exceptionally well.