[wting]

Could you expand into why you think this question is indicative of a workplace with "little-to-no learning" on the job?

I ask this question to new grad candidates with no expected answer in mind. The goal is to establish some level of technical competency and discover the candidates' interests. Do they talk about kernel, network, backend, frontend, etc?

The percentage of candidates who can spend more than 1 minute answering is abysmally low. If I get a curt response I'll follow up with relevant questions to the position they're applying for.

[cursork]

Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. 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. It's a bad signal.

Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.

There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.

Not a direct response, but expanding my thoughts slightly:

1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.

2. 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. I'd hate being pigeon-holed just because I happen to know one thing.

3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.

[lambda]

> 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.

[jwoah12]

I'm curious how long your screen generally lasts. In my hour-long phone screens there's barely enough time to cover a coding question and a few basic data structures/knowledge questions. I feel like covering everything you laid out would take several hours.

[lambda]

I try to keep it within an hour, but sometimes go over, up to an hour and a half.

I usually have the final question, writing real working code, be something that the candidate does offline using a real editor and being able to test it out, and email me the result afterwards, as we're usually low on time by that point and many people are more comfortable doing that in a real editor, being able to test out their code, etc. However, it turns out that the last question can be done as a one-liner shell script (it has one little tricky bit that make the simplest one liner shell script you might write not quite work properly, but it's possible to work around that), so some people are able to just do that online with me during the screen.

I generally keep the screen moving quickly, giving people prompts and hints to get past parts they're stuck on to keep things moving, and when I say I'm asking basic questions, they are really quite basic. My experience has been that people who actually pass the screen generally complete it within the hour, while people who are struggling are the ones who take longer.