4 ms·

Exactly. I've been asking this question for a long time, at least 10 years. I guess it's a joke now, but I still love it. If you asked me or some of my teammate

Exactly. I've been asking this question for a long time, at least 10 years. I guess it's a joke now, but I still love it. If you asked me or some of my teammates, we could talk for hours. Yet, we have candidates that finish the question in 30 seconds! They get a big nope from me, which brings me to another thing I like about this question... A lot of people just don't know how to react to it. I think it shows me what kind of thinker they are, ie do they need to be spoon fed or not? A lot of time, if I ask about some piece of this process, they can answer it. But they can't get to that piece on their own.

dsacco 9y ago
In fairness to those candidates, do you make your length or detail expectations explicitly clear? I've accepted someone's 30 second summary of TLS before as an interviewer because it was pretty clear they understood it at a high level, knew something meaningful about the process and would never be implementing anything like it (just relying on it). If I was asked this question I could probably ramble on for...oh, a half hour or so, if I actually exhausted my knowledge of keyboard interrupts, RAM, the TCP/IP stack (including specific packet headers and data frames and their lengths), hardware switching and routing, DNS lookups, HTTP, the TLS protocol (including which side does which part in which order), HTML/JavaScript parsing and client-side rendering. If I had to, I could talk less confidently about relative latencies and performance for all of those things too. How much signal does that question actually carry? I can give you a lot of true information, but is it useful for knowing if I can properly code or debug existing software? For example, I could drill down into TLS specifically for another half hour - I probably couldn't actually write a TLS stack without referring to a lot of pre-existing literature, and even then it wouldn't be safe to use and I'd likely make critical mistakes. That's a crypto example but I think it applies to a lot that's here. This question feels like one that doesn't really know what it's looking for, which I personally feel happens a lot in "open ended questions." If you need to test someone's knowledge of memory and latency, tailor the interview for that. If you need to know how well they understand HTTP and HTML/JavaScript, tailor your questions for that. But this question is sort of unreasonable for a lot of people because I think you'll get a few types of answers, among the set who can answer it well: 1. People who can speak for literally hours about everything that happens and who really know what they're doing, but who give a concise summary in a minute or two because the question is ridiculously underspecified and they really don't know where to go with it (this is worst case scenario, because these candidates might be dismissed for not being able to get to the meat on their own, when really they just recognize it's a gargantuan question and they're not sure how far you want them to go). 2. People who know all of it extremely well (like 1), but who hate the question and parody it by drilling down into mind-numbing detail about one particular part that is minutia for the actual job (e.g. they give you a treatise on multi-process browser architecture that could be a conference talk with some more polish). Ask for another detail and they'll punish you for asking by drilling down into something else that's literally what you meant but vaguely misses the point. Do you fail the candidate on the question because they're being passive aggressive or accept that they know an incredible amount about it and are expressing it's a bad question? 3. People who know one or two parts extremely well and who know the rest to a shallower (but still correct) depth (I fit into this category, in that I know the crypto and networking very well but am fuzzy on everything else more than two meaty question-response cycles down on the topic). Posed with this question, they'll most likely give a good first order explanation of how each part works or just skip it (e.g. people rarely even talk about the keyboard, USB, etc and just skip to the networking, passing over RAM completely), followed by a reasonably well explained overview of whichever part they're confident in. This isn't to criticize you or the other commenters at all, it's just my bias in the other direction. I don't typically like "open ended" questions because I feel they are underspecified versions of the questions you really want to get at, and a candidate can know the topic really well but sort of flub them. If I was hiring someone to literally work on writing a browser I'd probably ask this question but...that's about it, I think.

dsacco 9y ago

In fairness to those candidates, do you make your length or detail expectations explicitly clear? I've accepted someone's 30 second summary of TLS before as an interviewer because it was pretty clear they understood it at a high level, knew something meaningful about the process and would never be implementing anything like it (just relying on it). If I was asked this question I could probably ramble on for...oh, a half hour or so, if I actually exhausted my knowledge of keyboard interrupts, RAM, the TCP/IP stack (including specific packet headers and data frames and their lengths), hardware switching and routing, DNS lookups, HTTP, the TLS protocol (including which side does which part in which order), HTML/JavaScript parsing and client-side rendering. If I had to, I could talk less confidently about relative latencies and performance for all of those things too. How much signal does that question actually carry? I can give you a lot of true information, but is it useful for knowing if I can properly code or debug existing software? For example, I could drill down into TLS specifically for another half hour - I probably couldn't actually write a TLS stack without referring to a lot of pre-existing literature, and even then it wouldn't be safe to use and I'd likely make critical mistakes. That's a crypto example but I think it applies to a lot that's here. This question feels like one that doesn't really know what it's looking for, which I personally feel happens a lot in "open ended questions." If you need to test someone's knowledge of memory and latency, tailor the interview for that. If you need to know how well they understand HTTP and HTML/JavaScript, tailor your questions for that. But this question is sort of unreasonable for a lot of people because I think you'll get a few types of answers, among the set who can answer it well: 1. People who can speak for literally hours about everything that happens and who really know what they're doing, but who give a concise summary in a minute or two because the question is ridiculously underspecified and they really don't know where to go with it (this is worst case scenario, because these candidates might be dismissed for not being able to get to the meat on their own, when really they just recognize it's a gargantuan question and they're not sure how far you want them to go). 2. People who know all of it extremely well (like 1), but who hate the question and parody it by drilling down into mind-numbing detail about one particular part that is minutia for the actual job (e.g. they give you a treatise on multi-process browser architecture that could be a conference talk with some more polish). Ask for another detail and they'll punish you for asking by drilling down into something else that's literally what you meant but vaguely misses the point. Do you fail the candidate on the question because they're being passive aggressive or accept that they know an incredible amount about it and are expressing it's a bad question? 3. People who know one or two parts extremely well and who know the rest to a shallower (but still correct) depth (I fit into this category, in that I know the crypto and networking very well but am fuzzy on everything else more than two meaty question-response cycles down on the topic). Posed with this question, they'll most likely give a good first order explanation of how each part works or just skip it (e.g. people rarely even talk about the keyboard, USB, etc and just skip to the networking, passing over RAM completely), followed by a reasonably well explained overview of whichever part they're confident in. This isn't to criticize you or the other commenters at all, it's just my bias in the other direction. I don't typically like "open ended" questions because I feel they are underspecified versions of the questions you really want to get at, and a candidate can know the topic really well but sort of flub them. If I was hiring someone to literally work on writing a browser I'd probably ask this question but...that's about it, I think.