[rainboOow9]

What baffles me though is that its not like this crazy interview gauntlet is being maintained purely by HR. Engineers in those big tech companies are very protective towards those processes as well, and loudly protest if one would try to change them (complaining about lowering the bar, not hiring top tier talent anymore, etc.). And tbh, I would be afraid of what they would replace those LC interviews with. At least, I can prepare and grind a LC test. I do not want to have to explain in details what a inode is when interviewing for a back-end position, while I have never had a need for that kind of knowledge in 10 YoE.

[fnimick]

Amusingly, I have gotten exactly that question - or rather, "what's in an inode." I answered "data about a file object, but none of the actual contents of the file, which are stored elsewhere" and failed because I didn't mention the magic words "metadata" and "permissions". Fair, I guess, but this wasn't for a systems development position at all, so I can't imagine it would have been critical to the job!

Another favorite of mine, for a web development position, was "what happens at the network level when you load a webpage" where I got marked as getting it wrong for skipping explicit description of SYN/ACK step of the TCP connection. Again, fair, but probably not relevant.

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

[AnIdiotOnTheNet]

> Engineers in those big tech companies are very protective towards those processes as well, and loudly protest if one would try to change them (complaining about lowering the bar, not hiring top tier talent anymore, etc.).

Hazing is a feature of almost every organization that is regularly recruiting new members.

[rainboOow9]

Is it though? Seems pretty specific to the tech industry (and some others).

Never heard that there were crazy interview rounds for experienced lawyers, marketers, project managers, even other non-tech engineers. After a certain amount of experience, people assume from your resume that you are not an impostor and interviews are mostly about motivations / behavourial fit.

[lowercased]

I don't know how much those other professionals are 'managed' in a daily sense.

I worked in a law firm for a while, and didn't see the 'daily scrum/standup' thing done, even when multiple lawyers were working on the same case. They would certainly have regular meetings, and direct support staff to do certain things.

I was only a delivery/courier person, so certainly wasn't privileged to hear every case detail, but I was friends with someone whose mom was effectively the office manager. She knew most practical details about the cases - court dates, filing dates, parties, procedures, etc, but would never dream of telling any of the lawyers how to lawyer. She might remind them of due dates, but she didn't set the dates either - the courts did that.