[some_furry]

As someone who uses questions like this in interviews, the entire point of these kinds of questions is to see where the candidate takes you.

If you want to spend 20 minutes talking about DNS, I'm going to ask a lot of follow-up questions throughout the process, not fail you for not meeting a rubric or magic list of buzzwords. My goal will be to see how deep your knowledge on a particular piece of technology is, especially for a security role.

The problem here isn't the question; the question is a tool. The problem is that the interviewer isn't using the tool appropriately.

(Note: I don't choose these questions, the team I work for did. I follow a script, and it includes questions like this. But the script also contains a reminder for how to use the damn question.)

[grog454]

If I was given this question my first inclination would be to ask what your current understanding of the process is and you want to know. If that didn't help, I'd start with the absolute highest level "the google.com website loads in the area below the address bar" and then I'd be back to "what else do you want to know?". Hopefully that would be enough for you to start narrowing in (what does "load" mean and how does that work?).

Opening with DNS, HTTPS, TCP, etc. could end up being a complete waste of time depending on what signals your looking for, what you're really asking, and your background. I'm curious how my responses would be interpreted by you as someone who's asked questions like this before?

[some_furry]

I would ask probing questions like "how does the area below the address bar know which website to load?"

Like, my goal isn't to see how much of a spiel you've rehearsed for a finite set of possible interview questions.

That sort of exercise constitutes a useless hazing ritual that selects for people with low anxiety at the moment, not aptitude with the relevant technologies for the job.

I'm going to keep pushing the conversation along until you've either hit the depth of your knowledge and say "I'm not sure", or we need to move onto other questions. If we hit your depth early but we're headed into an interesting direction, I might ask, "How would you build [protocol or feature you're not sure about]?" This potentially gives useful data in how you, as a candidate, approach abstract problems.

But I should also note: I'm an introvert. I'm shy. I get nervous easily in social situations. I'm not the best interviewer, and I don't believe the processes I learned from my employers are necessarily the right way to hire technical expertise. I would rather replace the interview with timeboxed work-sample tests. But I don't call those shots.

[kevstev]

Completely agree, and its very telling almost immediately in these types of questions how technical you are. If you say "it asks the webserver for a webpage" in almost all cases there is a superficial knowledge compared to someone who opens with "a DNS resolution request is made to get the IP of the server, then we send an HTTP get request to that server with a URL..." and from there we can dive in to how DNS works, how TCP/IP works, what a typical webserver does, what are the http verbs, etc...

With the first type of response, when you follow up with how do we know where the webserver is, there is usually uncertainty. The whole point of open ended questions is to understand where your technical understanding is, not to hit a bunch of keywords on the way. This type of question though is way outside the norm though, I think it is a misunderstanding on the interviewee's part if they think this is an exercise in saying specific terms. I can see how its potentially more frustrating- there is no pass/fail, just how well did you do on a scale that is a bit subjective.