| > Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed. > I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer. > I know many highly able programmers who wouldn't know how to respond given so many options If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?" When I ask a question like this, I'm not trying to be tricky, but trying to ask a question that should involve knowledge that just about every competent programmer should have, and see how well they can break it down, explain it, stop at the part where their knowledge runs out rather than making things up or guessing. I've had people guess on this question, completely getting it wrong when I ask something like "and so what is the difference between TCP and UDP", and I find that even worse than just saying "I don't know how that part works"; if someone knows what they don't know, they will know when to ask questions, but if they just make stuff up to try to make themselves sound more knowledgeable, I don't know if I could ever trust their knowledge or judgement because it could be based on them just covering up a lack of knowledge about something. > Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. Yeah, I don't ask this question to tell what someone's interested in. I ask it to determine (a) if they have enough experience that they have done at least some looking into how the stack works enough to discuss it intelligently and (b) whether they are capable of breaking down and explaining a complex piece of technology with several interacting parts. For the jobs I'm hiring for, understanding the basics of how the network works is pretty much a requirement. If someone doesn't know how DNS and TCP work, asking them to debug a complex performance problem with a distributed filesystem communicating with dozens of clients over a 40 G backend network and 10 G frontend is probably going to be asking a bit much of them. Even for the more basic application development tasks, almost everything we do touches the network somehow. And if someone does actually discuss the details of input getting from the keyboard into the kernel, and from there into the browser, and it handling the event, and so on, then that does provide me with information that they know that portion of the stack well; I don't expect everyone to know everything, but I do want people who are interested enough to at least have some basic knowledge of how the fairly complex system that they use on a day to day basis works. > > Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed. > I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer. > I know many highly able programmers who wouldn't know how to respond given so many options If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?" > There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even. Yes, you would not use this as a sole interview question. This should generally be used as one of several. My basic screen consists of: write up a basic algorithm in pseudocode, compare and contrast data structures and running times for a couple of basic tasks, the "what happens when I enter google.com into my browser and press enter" question, a question on designing a class hierarchy for modelling a particular problem, a question on debugging where I lead them through a problem I've actually had to debug and see what kinds of suggestions they make about things to look for and ways to figure out what's going on, and then an actual coding problem where I expect them to provide real code to solve a simple problem. I don't expect everyone to be an expert on all of these. Some people haven't ever taken a formal algorithms and data structures course, or it's been 20 years since they did so, so they haven't really thought about asymptotic running time in a long time. That's OK, as long as they do well on the others. Or some people may not know much about networking, but are strong in the other areas; that's fine too. But if someone doesn't know much about networking, or algorithms, can't design an appropriate class hierarchy and interface, and can't really offer very good suggestions for how they would debug a problem that we encounter variations of fairly often here, I wonder whether they really are going to be able to contribute effectively. Or if they can talk a lot about the data structures and networking, but then fail at actually writing pseudocode to solve a basic algorithmic problem (and I'm talking very basic, like you should be able to do this in a CS 101 class) or fail at actually producing working code for the simple coding problem, I feel like they may have some good domain knowledge but don't actually have the skills necessary to actually contribute. |