6 ms·

This goes on the list of interview questions that's great at letting the interviewer claim pretty much any candidate they want to discard is unworthy of the pos

by akerl_ 11y ago

This goes on the list of interview questions that's great at letting the interviewer claim pretty much any candidate they want to discard is unworthy of the position. It's the tech community's variant of a voting literacy test. If you ask me "how does the internet work" and what you really want is details on the underlying protocols, at around the range of TCP/IP, why aren't you actually asking for that? Your question is so broad that it's not shocking in the slightest that most people pick a different focal point for their answer, especially given the already hostile interview environment and the added agitation provided by such an unclear question. If your goal is to elicit and understanding of somebody's background in TCP/IP and the surrounding protocols, ask them a question about that. If that's not relevant for the position (it's almost certainly not for most "full-stack" engineers), switch to asking questions that are relevant to the work they'll actually be doing.

mikehollinger 11y ago
this. I'll chime in as someone with a skill set that is completely not special (linux application development, and hardware / firmware / software integration), but in certain circles, is unique since it doesn't involve JavaScript (yet). I think the question is too vague, but I've asked a similar question: To kernel hackers (not application developers) - Tell me what you know about the Linux boot process To anyone with a 5th-gen language on their resume: how's a hash table implemented? (use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct)
- akerl_ 11y ago
  I'd argue that the cases where a hash table's performance characteristics come into play are few and far between for most developers, and when they do, it's way more relevant that the person have a general idea how to profile perf in their code and say "yup, this is the spot that I need to worry about optimizing first". By marking down people who don't know how to implement a hash table, you're cutting out a large chunk of your candidate pool, and I'm willing to stake my hiring choices on the fact that a decent chunk of them could easily by taught that knowledge if it became relevant for their career on your team.
  - a8da6b0c91d 11y ago
    > "yup, this is the spot that I need to worry about optimizing first". This almost never actually happens. In practice slow software of any size and complexity is sprinkled with many small inefficiencies that add up and no single thing makes a huge difference. To be performant you have to write with performance in mind from the get-go and not make many small mistakes.
    - plonh 11y ago
      And "what implementation to use for a map" is a decision nobody makes at first, as it depends a lot on hownit ends up used. In reality there are a few worst spots in our code. Being 2x too slow isn't big a deal except in the rare cases where your whole business is turning compute resources into money withn no other expenses. Investing programmer energy in features and correctness is a better use than premature optimization, say, 97% of the time.
  - davnicwil 11y ago
    I did an interview once where they asked me questions around the implementation of a hashmap. At the time I'd been working about a year out of university, and had not in that job come across any situation where I'd needed to know anything about how hashmaps worked under the hood (if anyone had a first job where you did, I'm happy for you, yours was a lot more interesting than mine). Any remnant of an explanation I'd got from my CS degree, most likely in first year, was way back in the mists of time. In the pressured situation, I simply admitted I didn't know. At this point the interviewer's face soured, and he basically wrapped up the interview straight away - it had been running about 5 minutes at that point, with only one question before that, so it was pretty obviously being cut short. Immediately after the interview I went to Wikipedia to look up hashmaps, instantly understood the basic mechanics, and 5 minutes later could have given a stellar answer to that question. If that interviewer was looking for someone with an encyclopaedic knowledge of data structures, with flawless recall under pressure, then his question served him well in filtering me out. I sincerely doubt that's what he was looking for, though. Since that experience I've been very careful, doing interviews myself, never to ask straight-up knowledge questions like this - or at least if I veer into a question like that, allow the candidate to explore the idea (even tell them the answer, and just talk about it to see if they get it) if they initially don't know. That will get you a lot closer to what you're actually trying to assess them for. It's very easy to fall into a trap of interviewing with a 'mirror' approach, where you assume that the candidate must know what you know, or else be bad. Kind of a paint by numbers, where the finished product looks a lot like you. But everyone learns on a different path. You need to remember that there was a time where each concept you use take for granted every day in your job was once new and alien to you, too. You picked it up just fine, and so can they. In fact, this is by far the most core skill you are looking for - that ability to actually pick up new things and use them.
- bpicolo 11y ago
  > use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct Which you shouldn't worry about until a profile shows it's an issue. Otherwise, having a basic understanding of data structure usage is the actual critical bit
  - nirvdrum 11y ago
    Given the choice between two functionally correct data structures with different performance profiles, you should pick the one more appropriate to the task at hand. A lot of performance issues can be proactively avoided with a bit of analytical thinking, but you do need to know how your data structures work and what their trade-offs are. Profilers are wonderful tools, but in the 15 years I've been professionally writing software the number of people I know that have ever used one numbers in the low 10s. Of those, the number that can derive meaningful data from a profile is even smaller. And finally, those that can spot "death from a thousand cuts" situations (quite common) from the proverbial method that takes 20% of all CPU time is even smaller yet. Profiling has a place, of course. But it's tricky to get right, incredibly time consuming without sampling, and often doesn't give you a complete picture. It's the performance equivalent of a debugger and really should be a fallback, not the only tool in your arsenal.
  - AnthonyMouse 11y ago
    That doesn't necessarily work at the level of fundamental data structures. If you make the same mistake in 1500 different places the profiler won't show any of them as particularly hot but your program will still be slow.
- kybernetikos 11y ago
  > to anyone with a 5th-gen language on their resume: how's a hash table implemented? use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct) Someone recently argued something similar with me, although they were even more emphatic about the importance of taking an interest in how the datastructures you're using are put together. Interestingly though, there are a few well known languages where if you assumed that the default Map was implemented as a Hashtable, you'd be making bad assumptions, as it's a Hash Array Mapped Trie, a data structure that certainly wasn't taught back when I was studying computer science. Unsurprisingly, despite the strong opinion that you should always find out how the things you use are implemented, my interlocutor didn't know this. And I didn't expect him to. I think that an obsession with particular shibboleths that "any decent programmer should know" misses the point that you're a decent programmer because of what you can do when you need to, not because of the datastructure implementations you've memorised.
  - Retra 11y ago
    People vastly underestimate the amount of useful information that exists that you could learn. If someone asked me why I don't know some micro-fact, I'd want to respond by saying "because I've learned these other 10 things instead." If you spend all your time learning some particular domain of knowledge, you're not going to be prepared to ask questions about the domains you don't know. And most people will have a hard time seeing the value in those things they didn't learn. Especially when they're playing an authority figure.
spydum 11y ago
i think perhaps there is a misconception: the idea for a sufficiently vague answer is to see how deep the person can go. a non-answer isn't such a big deal (if someone doesnt know, better for them to say it than to make up some nonsense). also depends on the role. if i were interviewing for a network engineer, you better believe i expect the person to talk about IP/BGP/routing tables, and ideally be able to talk transport protocols and further. if they have no idea, and just know how to "conf t" or click in a GUI, thats pretty informative.
- akerl_ 11y ago
  Which is why, thankfully, it's possible for the interviewer to have a dialogue. You don't have to lead in with "How does the internet work" to get that level of depth, and in fact it's not usually the best way to find if a candidate can deep dive. You can lead in by asking the candidate how something higher-level works, and then as they provide feedback, take the conversation towards lower-level network protocols and layers. That way, the person answering doesn't need to guess either your desired starting depth or direction, and they can focus on communicating their knowledge to you. Interviews tend to be far more productive when everybody involved is working to help the candidate provide as much of their knowledge as possible, without setting up confusing questions or overly hostile hurdles to "challenge" them.
acdha 11y ago
I agree the potential for error needs to be actively corrected against but I think this class of question can be quite useful for seeing where someone has worked and, ideally, where they're comfortable saying “I don't know”. For web developer positions, one of my favorite questions is “I'm looking at a “Buy Now” button on a web page. What happens when I click it?” with follow-up questions to expand if someone gets stuck on a tangent. I like that more than the form above because it allows anyone to focus on the areas they know more about – e.g. a JS dev will talk about events, client-side validation, etc. a lot more than a backend person. Some of the best people simply got to a point where they said something like “I know SSL is involved but I haven't had to work on that”; some of the classic overconfident promoters feel they have to explain everything and cook up some very fanciful stories, like the guy who told me HTTPS transactions happen over a leased-line connection separate from the Internet for security.
- loup-vaillant 11y ago
  > […] comfortable saying “I don't know”. For this particular question (How does the internet work?), I'd probably shot back "What do you mean?" or something along those lines. "I don't know" is for specific enough questions. This one is just asking for feedback.
vinceguidry 11y ago
> If you ask me "how does the internet work" and what you really want is details on the underlying protocols, at around the range of TCP/IP, why aren't you actually asking for that? Because the more specific the question, the less likely any interviewee is going to be able to answer it correctly. > If that's not relevant for the position (it's almost certainly not for most "full-stack" engineers), switch to asking questions that are relevant to the work they'll actually be doing. A full-stack engineering position is really broad in scope. You need to be able to handle any type of web-related task they throw at you. From architecting new features to troubleshooting slowness. You're expected to be a hammer they can swing at all their technical problems, which all look like nails to them. Don't like it? Too bad, that's the job. Where a general "how does the Internet work" question fits in is, ok, you've got complaints coming in from customer service about site slowness. How do you start to troubleshoot this problem? At what point can you just say, "oh, it's not us, it's with the Internet," and will you be able to explain why it's not us to the satisfaction of the people paying you to know about these things? The more abstract, fundamental knowledge you have about how the Internet works, the more you can start to nail down the scope of the problem. Also, some problems will have you writing custom protocols. It helps to not get lost.
codingdave 11y ago
I disagree. It is like FizzBuzz for sysadmins. Being able to answer does not mean you should get the job, but an utter failure to answer should absolutely disqualify you. Once you make that basic determination, other questions should be used to judge actual fit for the job at hand.
- morgante 11y ago
  > I disagree. It is like FizzBuzz for sysadmins. Why would you give a "FizzBuzz for sysadmins" question to full-stack developers though?
  - codingdave 11y ago
    Ah, good point. I jumped tracks there. But it may still be a valid question, you just would not expect the same level of detail. I do believe that developers should at least understand the basic concepts of how the web works. Maybe not the structure of a TCP packet, but certainly how DNS and IP addressing work, and the flow of data between a server and a client as web/mobile apps are loaded.
hughw 11y ago
> If you ask me "how does the internet work" and what you really want is details on the underlying protocols, at around the range of TCP/IP, why aren't you actually asking for that? To see if you know what "how the internet works" even means. It's not an ambiguous question. If you respond with a description of Ruby on Rails, out you go!
- bloaf 11y ago
  "How does the internet work?" Well, you see, when two computers love each other very much...

by akerl_ 11y ago

mikehollinger 11y ago

this. I'll chime in as someone with a skill set that is completely not special (linux application development, and hardware / firmware / software integration), but in certain circles, is unique since it doesn't involve JavaScript (yet). I think the question is too vague, but I've asked a similar question: To kernel hackers (not application developers) - Tell me what you know about the Linux boot process To anyone with a 5th-gen language on their resume: how's a hash table implemented? (use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct)

akerl_ 11y ago
I'd argue that the cases where a hash table's performance characteristics come into play are few and far between for most developers, and when they do, it's way more relevant that the person have a general idea how to profile perf in their code and say "yup, this is the spot that I need to worry about optimizing first". By marking down people who don't know how to implement a hash table, you're cutting out a large chunk of your candidate pool, and I'm willing to stake my hiring choices on the fact that a decent chunk of them could easily by taught that knowledge if it became relevant for their career on your team.
- a8da6b0c91d 11y ago
  > "yup, this is the spot that I need to worry about optimizing first". This almost never actually happens. In practice slow software of any size and complexity is sprinkled with many small inefficiencies that add up and no single thing makes a huge difference. To be performant you have to write with performance in mind from the get-go and not make many small mistakes.
  - plonh 11y ago
    And "what implementation to use for a map" is a decision nobody makes at first, as it depends a lot on hownit ends up used. In reality there are a few worst spots in our code. Being 2x too slow isn't big a deal except in the rare cases where your whole business is turning compute resources into money withn no other expenses. Investing programmer energy in features and correctness is a better use than premature optimization, say, 97% of the time.
- davnicwil 11y ago
  I did an interview once where they asked me questions around the implementation of a hashmap. At the time I'd been working about a year out of university, and had not in that job come across any situation where I'd needed to know anything about how hashmaps worked under the hood (if anyone had a first job where you did, I'm happy for you, yours was a lot more interesting than mine). Any remnant of an explanation I'd got from my CS degree, most likely in first year, was way back in the mists of time. In the pressured situation, I simply admitted I didn't know. At this point the interviewer's face soured, and he basically wrapped up the interview straight away - it had been running about 5 minutes at that point, with only one question before that, so it was pretty obviously being cut short. Immediately after the interview I went to Wikipedia to look up hashmaps, instantly understood the basic mechanics, and 5 minutes later could have given a stellar answer to that question. If that interviewer was looking for someone with an encyclopaedic knowledge of data structures, with flawless recall under pressure, then his question served him well in filtering me out. I sincerely doubt that's what he was looking for, though. Since that experience I've been very careful, doing interviews myself, never to ask straight-up knowledge questions like this - or at least if I veer into a question like that, allow the candidate to explore the idea (even tell them the answer, and just talk about it to see if they get it) if they initially don't know. That will get you a lot closer to what you're actually trying to assess them for. It's very easy to fall into a trap of interviewing with a 'mirror' approach, where you assume that the candidate must know what you know, or else be bad. Kind of a paint by numbers, where the finished product looks a lot like you. But everyone learns on a different path. You need to remember that there was a time where each concept you use take for granted every day in your job was once new and alien to you, too. You picked it up just fine, and so can they. In fact, this is by far the most core skill you are looking for - that ability to actually pick up new things and use them.
bpicolo 11y ago
> use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct Which you shouldn't worry about until a profile shows it's an issue. Otherwise, having a basic understanding of data structure usage is the actual critical bit
- nirvdrum 11y ago
  Given the choice between two functionally correct data structures with different performance profiles, you should pick the one more appropriate to the task at hand. A lot of performance issues can be proactively avoided with a bit of analytical thinking, but you do need to know how your data structures work and what their trade-offs are. Profilers are wonderful tools, but in the 15 years I've been professionally writing software the number of people I know that have ever used one numbers in the low 10s. Of those, the number that can derive meaningful data from a profile is even smaller. And finally, those that can spot "death from a thousand cuts" situations (quite common) from the proverbial method that takes 20% of all CPU time is even smaller yet. Profiling has a place, of course. But it's tricky to get right, incredibly time consuming without sampling, and often doesn't give you a complete picture. It's the performance equivalent of a debugger and really should be a fallback, not the only tool in your arsenal.
- AnthonyMouse 11y ago
  That doesn't necessarily work at the level of fundamental data structures. If you make the same mistake in 1500 different places the profiler won't show any of them as particularly hot but your program will still be slow.
kybernetikos 11y ago
> to anyone with a 5th-gen language on their resume: how's a hash table implemented? use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct) Someone recently argued something similar with me, although they were even more emphatic about the importance of taking an interest in how the datastructures you're using are put together. Interestingly though, there are a few well known languages where if you assumed that the default Map was implemented as a Hashtable, you'd be making bad assumptions, as it's a Hash Array Mapped Trie, a data structure that certainly wasn't taught back when I was studying computer science. Unsurprisingly, despite the strong opinion that you should always find out how the things you use are implemented, my interlocutor didn't know this. And I didn't expect him to. I think that an obsession with particular shibboleths that "any decent programmer should know" misses the point that you're a decent programmer because of what you can do when you need to, not because of the datastructure implementations you've memorised.
- Retra 11y ago
  People vastly underestimate the amount of useful information that exists that you could learn. If someone asked me why I don't know some micro-fact, I'd want to respond by saying "because I've learned these other 10 things instead." If you spend all your time learning some particular domain of knowledge, you're not going to be prepared to ask questions about the domains you don't know. And most people will have a hard time seeing the value in those things they didn't learn. Especially when they're playing an authority figure.

spydum 11y ago

i think perhaps there is a misconception: the idea for a sufficiently vague answer is to see how deep the person can go. a non-answer isn't such a big deal (if someone doesnt know, better for them to say it than to make up some nonsense). also depends on the role. if i were interviewing for a network engineer, you better believe i expect the person to talk about IP/BGP/routing tables, and ideally be able to talk transport protocols and further. if they have no idea, and just know how to "conf t" or click in a GUI, thats pretty informative.

akerl_ 11y ago
Which is why, thankfully, it's possible for the interviewer to have a dialogue. You don't have to lead in with "How does the internet work" to get that level of depth, and in fact it's not usually the best way to find if a candidate can deep dive. You can lead in by asking the candidate how something higher-level works, and then as they provide feedback, take the conversation towards lower-level network protocols and layers. That way, the person answering doesn't need to guess either your desired starting depth or direction, and they can focus on communicating their knowledge to you. Interviews tend to be far more productive when everybody involved is working to help the candidate provide as much of their knowledge as possible, without setting up confusing questions or overly hostile hurdles to "challenge" them.

acdha 11y ago

I agree the potential for error needs to be actively corrected against but I think this class of question can be quite useful for seeing where someone has worked and, ideally, where they're comfortable saying “I don't know”. For web developer positions, one of my favorite questions is “I'm looking at a “Buy Now” button on a web page. What happens when I click it?” with follow-up questions to expand if someone gets stuck on a tangent. I like that more than the form above because it allows anyone to focus on the areas they know more about – e.g. a JS dev will talk about events, client-side validation, etc. a lot more than a backend person. Some of the best people simply got to a point where they said something like “I know SSL is involved but I haven't had to work on that”; some of the classic overconfident promoters feel they have to explain everything and cook up some very fanciful stories, like the guy who told me HTTPS transactions happen over a leased-line connection separate from the Internet for security.

loup-vaillant 11y ago
> […] comfortable saying “I don't know”. For this particular question (How does the internet work?), I'd probably shot back "What do you mean?" or something along those lines. "I don't know" is for specific enough questions. This one is just asking for feedback.

vinceguidry 11y ago

> If you ask me "how does the internet work" and what you really want is details on the underlying protocols, at around the range of TCP/IP, why aren't you actually asking for that? Because the more specific the question, the less likely any interviewee is going to be able to answer it correctly. > If that's not relevant for the position (it's almost certainly not for most "full-stack" engineers), switch to asking questions that are relevant to the work they'll actually be doing. A full-stack engineering position is really broad in scope. You need to be able to handle any type of web-related task they throw at you. From architecting new features to troubleshooting slowness. You're expected to be a hammer they can swing at all their technical problems, which all look like nails to them. Don't like it? Too bad, that's the job. Where a general "how does the Internet work" question fits in is, ok, you've got complaints coming in from customer service about site slowness. How do you start to troubleshoot this problem? At what point can you just say, "oh, it's not us, it's with the Internet," and will you be able to explain why it's not us to the satisfaction of the people paying you to know about these things? The more abstract, fundamental knowledge you have about how the Internet works, the more you can start to nail down the scope of the problem. Also, some problems will have you writing custom protocols. It helps to not get lost.

codingdave 11y ago

I disagree. It is like FizzBuzz for sysadmins. Being able to answer does not mean you should get the job, but an utter failure to answer should absolutely disqualify you. Once you make that basic determination, other questions should be used to judge actual fit for the job at hand.

morgante 11y ago
> I disagree. It is like FizzBuzz for sysadmins. Why would you give a "FizzBuzz for sysadmins" question to full-stack developers though?
- codingdave 11y ago
  Ah, good point. I jumped tracks there. But it may still be a valid question, you just would not expect the same level of detail. I do believe that developers should at least understand the basic concepts of how the web works. Maybe not the structure of a TCP packet, but certainly how DNS and IP addressing work, and the flow of data between a server and a client as web/mobile apps are loaded.

hughw 11y ago

> If you ask me "how does the internet work" and what you really want is details on the underlying protocols, at around the range of TCP/IP, why aren't you actually asking for that? To see if you know what "how the internet works" even means. It's not an ambiguous question. If you respond with a description of Ruby on Rails, out you go!

bloaf 11y ago
"How does the internet work?" Well, you see, when two computers love each other very much...