[chasd00]

> where I got marked as getting it wrong for skipping explicit description of SYN/ACK step of the TCP connection

that's pretty crazy because if you're going to talk about that then you're going to have to talk about congestion control, windowing, every other protocol besides IP that TCP can run on top of and how they work, and all the other things that come into play based on the current state of the various networks between you and the server hosting the website. Answering that one question could take an hour itself. It reminds me of that saying that goes like "How to make an Apple Pie. Step 1, create the universe..."

I'm very fortunate because my last three interviews have been basically calling up an old colleague and asking what they've been up to and if they want some help.

[jasonladuke0311]

And this is why I hate those "Tell me what happens when you type google.com into your browser" questions. Unless the interviewer is VERY active in guiding the discussion, I have no idea how to proceed. I could probably talk about DNS for 20 min. I totally bombed this question in an interview once because I got like zero feedback during the discussion.

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

[citizenpaul]

Yeah that stuff is awful. Plus you have to judge if the people you are talking to are technical or just waiting for you to hit keywords. I've actually been to an interview where I just rattled off keywords as answers and was offered the job but turned it down lol. Not cause of that but it was a gov job and the pay was awful, that was before I understood "Pay Ranges" meant bottom at gov jobs.