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