5 ms·

Do you find this an useful interview question in 2019? What is or isn’t useful about the answer from candidates?

by 0xEFF 7y ago

Blackthorn 7y ago
I do. If a candidate is a frontend developer and can't tell me anything beyond the absolute basics of how http works, that spells trouble.
owenmarshall 7y ago
I like it, especially for interviewing for ops/devops/sre/whatever we say today. It’s a good warm up question because pretty much any answer is right, and it quickly lets the candidate get to their comfort zone. It is also amenable to be simplified or tweaked - if the candidate doesn’t know much about CDNs or layer 7 load balancing or whatever, you just move past them. And you can change some of the parameters to be sure the candidate isn’t just memorizing the answer sheet. It can also give a strong signal where the candidate’s knowledge is weak: if you talk to me at length about Apache throwing read syscalls to pull files from the disk but quickly gloss over the networking bits, that might indicate you don’t know them well.
- GauntletWizard 7y ago
  This is precisely what I use it for, and precisely why I like answering it. I will talk in detail about the bits I know, smell bullshit (and look up answers) in the bits I don't, and it gives me an answer to candidates depth in all of them. Backend devs will talk about search and set theory algorithms. SREs will talk protocols. Networking guys will talk layer3-7. Everyone has their own style, and it's certainly the most informative in determining where to prove next. A good candidate had breadth and depth of knowledge. This one question shows breadth and tells you where to find depth. It doesn't work as well for pure frontend people, but only barely - I almost expect frontend people to understand interrupts and syscalls on that end.
  - devonkim 7y ago
    I expect front end people to be able to fire up developer tools and tell me where to troubleshoot slow network responses definitively as DNS related before filing a support ticket saying “my queries are slow because of DNS.” I wound up training network engineers how to use Chrome dev tools at a really large company because so many frontend developers knew absolutely nothing about troubleshooting network issues that they were disproportionately filing network support tickets. I usually try to focus on what the interviewer wants me to demonstrate knowledge on when I answer the question in an interview. As an interviewer I normally avoid the question and make it more job specific. I might ask about troubleshooting slow servers based upon an incident and try to determine the candidate’s thinking pattern and methodology. For developers it’s easier to ask “this block of code is not doing what I expected, what did I do wrong?” where the mistake is a very common one. I actually had a very practical HackerRank problem that asked me to troubleshoot a program and an accompanying docker compose file. If you had prior experience this would take you 2 minutes while you wonder if that’s really the whole problem.
irq11 7y ago
This question is now burnt. Nobody should be using it. (In reality, it was burnt a long time ago, but it’s crispy and black now.) If you do use it, you’re merely selecting for people who have read posts like this on HN and reddit. Candidates who have memorized any of this will look vastly superior to those who haven’t. It’s telling that there are already two sibling comments who are arguing that this is a good question - explains a lot about why technical interviews suck.
- brokenmachine 7y ago
  Just the fact those people are interested enough to read HN/Reddit for their own sake can't be a bad thing though. I'm not an employer but I know I'd rather my workmates were the kind of people who are actually interested in computers enough to read about them for pleasure, not just those "straight by the book" types.
  - toast0 7y ago
    The problem with this question is if someone gives a good answer, it can be hard to tell if they studied it or they actually know. Maybe you can suss this out with follow ups. If they don't give a good answer, maybe they haven't looked into networking details and debugging for some reason -- a lot of junior people haven't, but they may have the aptitude to learn and be great at it, but just don't have the knowledge base yet. Although it depends on exactly what you're hiring for, too. If you need the person like me, who will find and fix your weird problems with networking, maybe they should know this, or be able to make fairly plausible guesses; but most people on my team don't need to do that (although it's always nice to have more).
    - aaaaaar 7y ago
      "it can be hard to tell if they studied it or they actually know." What is the difference? If they studied it, they now know? Is it because as an interviewer, you are looking for knowledge by experience, not via book-learning?
      - 7y ago

Do you find this an useful interview question in 2019? What is or isn’t useful about the answer from candidates?

by 0xEFF 7y ago

Do you find this an useful interview question in 2019? What is or isn’t useful about the answer from candidates?

I do. If a candidate is a frontend developer and can't tell me anything beyond the absolute basics of how http works, that spells trouble.

owenmarshall 7y ago

I like it, especially for interviewing for ops/devops/sre/whatever we say today. It’s a good warm up question because pretty much any answer is right, and it quickly lets the candidate get to their comfort zone. It is also amenable to be simplified or tweaked - if the candidate doesn’t know much about CDNs or layer 7 load balancing or whatever, you just move past them. And you can change some of the parameters to be sure the candidate isn’t just memorizing the answer sheet. It can also give a strong signal where the candidate’s knowledge is weak: if you talk to me at length about Apache throwing read syscalls to pull files from the disk but quickly gloss over the networking bits, that might indicate you don’t know them well.

GauntletWizard 7y ago
This is precisely what I use it for, and precisely why I like answering it. I will talk in detail about the bits I know, smell bullshit (and look up answers) in the bits I don't, and it gives me an answer to candidates depth in all of them. Backend devs will talk about search and set theory algorithms. SREs will talk protocols. Networking guys will talk layer3-7. Everyone has their own style, and it's certainly the most informative in determining where to prove next. A good candidate had breadth and depth of knowledge. This one question shows breadth and tells you where to find depth. It doesn't work as well for pure frontend people, but only barely - I almost expect frontend people to understand interrupts and syscalls on that end.
- devonkim 7y ago
  I expect front end people to be able to fire up developer tools and tell me where to troubleshoot slow network responses definitively as DNS related before filing a support ticket saying “my queries are slow because of DNS.” I wound up training network engineers how to use Chrome dev tools at a really large company because so many frontend developers knew absolutely nothing about troubleshooting network issues that they were disproportionately filing network support tickets. I usually try to focus on what the interviewer wants me to demonstrate knowledge on when I answer the question in an interview. As an interviewer I normally avoid the question and make it more job specific. I might ask about troubleshooting slow servers based upon an incident and try to determine the candidate’s thinking pattern and methodology. For developers it’s easier to ask “this block of code is not doing what I expected, what did I do wrong?” where the mistake is a very common one. I actually had a very practical HackerRank problem that asked me to troubleshoot a program and an accompanying docker compose file. If you had prior experience this would take you 2 minutes while you wonder if that’s really the whole problem.

irq11 7y ago

This question is now burnt. Nobody should be using it. (In reality, it was burnt a long time ago, but it’s crispy and black now.) If you do use it, you’re merely selecting for people who have read posts like this on HN and reddit. Candidates who have memorized any of this will look vastly superior to those who haven’t. It’s telling that there are already two sibling comments who are arguing that this is a good question - explains a lot about why technical interviews suck.

brokenmachine 7y ago
Just the fact those people are interested enough to read HN/Reddit for their own sake can't be a bad thing though. I'm not an employer but I know I'd rather my workmates were the kind of people who are actually interested in computers enough to read about them for pleasure, not just those "straight by the book" types.
- toast0 7y ago
  The problem with this question is if someone gives a good answer, it can be hard to tell if they studied it or they actually know. Maybe you can suss this out with follow ups. If they don't give a good answer, maybe they haven't looked into networking details and debugging for some reason -- a lot of junior people haven't, but they may have the aptitude to learn and be great at it, but just don't have the knowledge base yet. Although it depends on exactly what you're hiring for, too. If you need the person like me, who will find and fix your weird problems with networking, maybe they should know this, or be able to make fairly plausible guesses; but most people on my team don't need to do that (although it's always nice to have more).
  - aaaaaar 7y ago
    "it can be hard to tell if they studied it or they actually know." What is the difference? If they studied it, they now know? Is it because as an interviewer, you are looking for knowledge by experience, not via book-learning?
    - 7y ago