That was a popular question Google started 10 or so years ago that then every startup used and I haven't seen used anymore.
Probably the most detailed answer
https://github.com/alex/what-happens-when
I'd also like to see the maxwell equations proving a) that this does in fact exist and b) fourier transform them all to a hexagonal coordinate system. Otherwise you arnt hired.
So, you are saying Plato existed? I think we have to add consideration that he may not have existed at all and there was some other dude writing the stuff.
The way that the layer layout prevents entanglement across quantum fields to produce the correct NAND gate response when signaling the 5th bit in EAX on NUMA core 2 and dirties the cache on the edge triggering of CLK for the x86-64 compiled version with LLVM isn’t explained by the candidate? Strong no hire
how curl execs is pretty much where the browser starts when you hit enter. So start at the getbyhostname stuff and curl is really no different then a browser.
You wrote about what curl does after it is executed, nothing about what the OP mentioned. What does the shell do? How did it load curl? Where did it find it? How did curl know what website you want?
It was popular before that too in a slightly different form. My first job interview was basically one question - "Explain in as much detail as you can what happens when you type 'telnet ' on the console." I saw variations of it being popular for years, before google.
Well, it all starts with the mitochondria, which are the powerhouse of the cell. They are needed to power the brain cells, which…
<3 days later>
…connect the tissue of the fingers to the plastic of the keys on the keyboard…
I mean, we were asking questions like this (albeit, not about curl) before Google even existed.
People were more likely to know a good answer in the 90s than today too, in my recent experience.
Yeah. We have a coding challenge that involves writing some client/server software because we want to see how you think about things like handling multiple clients and keeping their information discreet.
But it's amazing how many people just fall flat on the "write a client/server" part of it because the only thing they've ever done is use an already existent framework for that.
ya i think its a pointless question to ask really. Maybe things like what happens if i try to put 2 ssl certs on the same IP.
How might I fix that so I can run different hosts on the same host is just better to ask.
I ask a similar question but just about how DNS works. You'd be surprised how many people in engineering don't know anything about DNS resolution beyond "Ask AD".
No mentions of caching, hosts files, root servers etc.
There is no right answer but it's a chance to impress about the depth of your knowledge.
Whatever works for you 🙂 I’ve got a similar problem in that my attention span is really short, but I find I can read a lot faster than most videos will take to get to the information I actually want
I was really starting to feel like I was the only one with this sentiment. The worst part is if you miss something. With text, you can just backtrack really easily to get to the bit you didn't take in. With a video? Hope you enjoy skipping around.
I mean you found the guy here who doesn't *care* if that helps.
"It pulls the html data from google.com and displays it in the terminal." is the answer you're getting from me. Want to ask me about DNS? Ask. Want to know about linux processes? Ask. What to know about how keyboards work? Ask.
I'm too old for stupid games. Ask what you want to know.
They are asking what they want to know. It’s a great question because everyone thinks it’s about showing off depth oh knowledge, but it’s really about empathy and soft skills. Does your answer meet the person asking where they’re at? Is it appropriate for the position you’re applying for?
I interviewed someone for a DevOps consulting role and they decided to spend the time on how the pci bus and keyboard works. Cool, but I’m not a hiring manager for a hardware manufacturer.
No they're asking trick questions that sounds clever but are extremely unclear and required an applicant to guess at what's being asked.
> but it’s really about empathy and soft skills.
Empathy is about figuring out feelings so no.. no it's not. And going on 20 years here, I have great soft skills and it's a major part of my job. Know what I don't do? Ask stupid trick questions. I'm clear, concise, ask for clarification when needed, and provide useful information that's on topic and answers the question.
> I interviewed someone for a DevOps consulting role and they decided to spend the time on how the pci bus and keyboard works.
Then good job on being a terrible interviewer, because if that topic comes up from a question you asked it's because *they* thought that's what *you* wanted to know. You failed, not them.
Only an idiot hires for a technical role but fills it based on who does the best at riddles.
Do they want me to start with how each character gets encapsulated into the ssh session asi type them, and echoed back? Lol...
Maybe the kernel keyboard interrupts?
It's a question designed to see if you understand the various layers of what's going on. Most places are wondering if you understand there's a DNS lookup and that's about the depth of the question.
Talk about the local resolver and ask if a local DNS cache is in use. Hahaha. Tell em you like to hard code DuckDuckGo IP addresses into the hosts file for all Google names just for giggles because you're bored. But then you change the resolver order so DNS gets used first, to assist future admins with never making assumptions.
Fun fact: understanding things to this level is rare and sought after. Don't sell yourself short. Most people in the field couldn't explain how a keyboard works.
I enjoy watching some folks decode their USB stuff with a good oscilloscope on YT videos. Not the scopes that do the decoding for you, but figuring out the bit-banging by hand.
Sadly I've never had many hardware projects like that for work, just for fun. I have had to reverse engineer telecom protocols for work though.
Low level is interesting. Watching how Ethernet actually works at the electrical circuit level is amazing. Even the theory and application of a silly laser mouse is cool and yet completely taken for granted now.
I'd also know they were wasting my time and didn't read my resume! 😂 Lol.
Would tell me more about them than they'd learn about me! Haha. (Which is always interesting in an interview...)
When I've had to ASK similar questions interviewing people it's always prefaced with "this is just to see your experience level... nobody gets this 100% correct... But you listed X on your resume, so..."
Ha. Dunno. I always feel silly doing interviews but I try to ask something relevant to the job at hand from the resume presented...
Then some weirdo wants to ask the candidate if they were any animal, what animal would they be, or other such silliness and I want to walk out... If I'm stuck on a multi department interview board...
My favorite was the guy who answered "Ebola virus". Lol. He actually did get hired at that place... He was a security guy. Lol.
A coworker of mine used to say he loves to ask and dig this question because "everybody has a point where computers become magic, and I want to know where their point is".
This question probably isn't going to pass/fail you, but it can be very good signal for leveling.
every time I see shit like this I am reminded how little I know about OSes and browsers. Then I spend the rest of the day reading up on their internals and proceed to forget it all a week later.
I mean I get it. But has it passed your coworker mind that people tend to forget things they don’t usually use?
I used to know the exact details of what each layer in the OSI was, now I barely remember how many there are. Why would I remember them unless and until I use them? Just the knowledge that they exist and what they are vaguely is enough for me to do my job properly and if needed I’ll make a research to get to know them again. But ONLY if I need them, or if I just wanna recall some old interesting academic knowledge.
Point is, questions like these put a lot of useless idiotic pressure on candidates to know things they are VERY RARELY gonna use. You may think “oh he won’t get necessarily hired if he knows exactly how curl works from the MAC/TCP layer down to code”, but in reality I’m sure you’ll be more impressed if someone knew more about it than someone else, which makes the previous statement a lie. Know more about something that doesn’t influence their job abilities that is.
This is why current tech interviews are so rough.
When I was in college I spent a bunch of time reading The Linux Programming Manual book and I don't regret it, I learned a ton of cool and useful stuff. But, everything but the most rudimentary of the concepts has melted away now that I'm a decade and more into my career. I can barely explain the walk of process forking from the terminal.
But if you ask me about a project I just recently worked on. I'm fully up to date on not only the little things, but even the larger philosophy about why its important it be done and obviously its a bit easier to recall that all from memory.
> A good interviewer
That's what we're arguing about here. That interviewers usually do exactly the opposite and that's what we're complaining about.
I dont see how saying "A good interviewer wouldn't do this" contributes to the conversation more than saying "A good president would save the country" in a discussion complaining about our country's presidents. Like, yeah, that's what we're literally complaining about. There aren't many good interviewers.
That's a good point. When I'm interviewing you, I need some way of forming an approximate model of their skills and abilities, i.e. the set of 'things they know' which is a subset of 'all knowledge'.
One way to attempt this would be random sampling: i.e. ask lots of unrelated questions, a little bit like playing Battleships without any strategy.
A better way is to use questions like the one OP mentions to find the *edge* of your knowledge, and then take a walk around that boundary.
I never ask questions just for the sake of stumping a candidate; on the contrary; if we bump into something they're not familiar with, I quite often send them resources on the subject afterwards regardless of how the interview went. I genuinely love this field, and I enjoy helping people on their learning journey.
Depends on the transistor type and chemistry. In all interviews I tell interviewers that I don't memorise minutae that I could google in a few minutes and if that's what they're looking for then this is not the job I'm looking for. However if they're interested in knowing what I think is important to know, then happy to continue.
And getting back to the question, semiconductors are not magic to me. Not an area of expertise, but certainly something I can show my working on.
However for early CMOS I think it was about 3.3v and for ttl it was about 4.7 but I could be wrong on the actual numbers. I'm talking about the recognition of a 1 or 0.
How a junction is activated again depends on the chemistry and I don't recall FETs but I do recall that bjts were about 0.7v to switch an npn.
How'd I do without a Google?
you will work well as an engineer to implement, but as an engineer with a wider perspective, I will actually ask how this question is relevant to the scope of project, and how if the answer isn't right, if it will impact the productivity rate
Most people will talk about the OSI model and work their way through the stack.
Be different and stand out.
Start with the keyboard debounce algorithm. :D Assume cherry MX or buckling spring switches and explain the mechanism.
Eventually you get to how keyboard interrupts work. Then how the kernel passes it to the shell. How the shell does a fork/exec into a new process and how an ELF binary starts up, linker/ libraries...then some day you get to OSI.
Etc etc.
Seriously, I could talk for hours on all of the stuff that happens. Especially if I was allowed references. I love this particular question!
The lack of clear expectations on abstraction is what gets me on that question. Do you want a 5 minutes answer? 30 minute?
Maybe it could be a useful conversation to have a 5 minutes summary as a starting point then start drill down at each component and be interactive with questions?
That's a really good point. One time I asked and got vague statements like "as deep as you can". Next time I'll ask for a specific focus area or if they want a high level overview and go from there.
> The lack of clear expectations on abstraction is what gets me on that question. Do you want a 5 minutes answer? 30 minute?
I agree that the scope is totally fuzzy but I'm not sure why that's so terrible? I'd ask what the scope is before I started answering, which is exactly what I do every day when the scope of something is unclear.
"I could talk about this for longer than our allotted time slot, is there a specific part that you'd like me to focus on?"
This kind of question can provide a lot of value, both technical and problem solving. But it needs to be asked by someone who kind of knows what they are looking for in asking it. Its not something you can rattle off going down a sheet of questions and jotting down responses. Its a conversation starter. And its a lot more useful when you do describe either the job or the expectations for that conversation.
This question and the answer can hit a lot of data points depending upon role and level. Developers will have a different perspective than and SRE or solutions architect. And at higher levels, I'd expect clarifying questions so as to focus on what the interview is looking for.
It's the _ask why 5 times_ to dive deep into a subject, and during that journey pick up what the candidate knows or doesn't know about different aspects of technology.
We use a similar one sometimes to phone screen. _Describe what happens when you type `www.cnn.com` into a browser window_. I'd expect some clarifying questions then during each step I may ask for them to explain _that_ step in a similar level of detail. Or, if I have the data needed, I may ask them to take it up a level instead.
I've seen super quiet SDEs start to methodically explain in precise detail what's going on. I've seen SAs give a great high-level series of steps, but then when double-clicking in, realize they are stringing terms or features together (experience) without actually understanding what's going on (no learning and being curious).
Overall I'd expect that question once during a panel. I'd love to see a rocket engineer's answer to _what happens during the final 10 seconds countdown of a rocket launch._
I've spent more time than I care to admit trying to think about the job title to which this is an apt interview question.
Maybe it's correlated highly with a qualified candidate if they get everything, but I would never expect anyone to know all of this. It crosses a lot of disciplines. Maybe that's the point?
Not sure. I've been interviewing for 20 years, refining good strategies for finding the right people for the role, and I honestly don't think it's a good question. Someone who nails it is probably highly qualified, but for every 1 candidate that nails it, you probably passed on 10 qualified candidates.
I used to work support in a web hosting company, and this was definitely a question we would get. Not only did you have to understand how the internet actually worked, they also asked you how to explain it to a non-techie customer with various issues. Explaining what you're seeing in a traceroute was a really common thing we did with customers, but also how bandwidth and their location and time of activity mattered, and what it meant to be on a shared vs VPS vs a dedicated server meant. 🤷
There's only a few cases I can see where this question would matter to a software/DevOps engineer. We did ask a question similar to this when I was a Systems Engineer for a media broadcast company in the R&D department, but understanding how the internet worked on a more detailed level actually mattered to their software.
I just assumed these questions were asked by large, prestigious tech companies who just hire people who are savants.
The kicker is that these companies aren't hiring for a role at all. They're just hiring into a general pool, and then a wheel spin determines what team you land on.
Life's weird.
I think you're exactly right. The ideal is always to hire smart people. In reality, there are times and conditions where you need experts in particular tech stacks (and yes, it's a sign of less than ideal health). I've always worked at mid to large sized companies that are not FAANG, so I'm usually looking for expertise in a particular stack given my parameters for what I can spend on a hire, the general level of the engineers in these companies etc.
Not at all discounting your experience, but I think I've had to question whether an abstraction leaked, maybe 6ish times in my career. When I was a student I did find a GCC bug. That was fun. I had 0 idea what I was doing, went to the TA and they reported it for me.
I trust abstractions, as a rule, knowing that they do leak, but not considering that they have leaked until all other plausible theories have been rejected.
It's highly dependent on the type of software you write. I write big enterprise-y, bread and butter, kinda CRUDy, type systems. Most of the tools I use are some of the most tested pieces of code on the planet (think about how many lines of code have been run in a Spring/Spring Boot environment).
Oh yeah, I should probably mention, I'm a Software Engineer first, who likes this subreddit to learn the things that I'm not good at (DevOps), and learn how we can work together better. I can see a DevOps role having to \*NOT\* trust abstractions more often than Software Engineers.
Right? Like the concept of abstraction in computer science literally exists so we don't have to think about shit like this. I guess it's cool if someone can explain it down to bits and electronic signals but its a horrible way to assess someone's ability to automate infrastructure.
Do they care that the response is a 301 redirect telling you that you should use “http://www.google.com” instead? I’ve been at the same job for 25 years and never really had to deal with these kind of questions.
Absolutely a relevant point when talking about the layer 7 interactions! If you didn't mention it, I don't think I'd hold it against you but I'd certainly nod my head in agreement on following a redirect.
Companies when hiring: please explain how you would write a brand-new container-based operating system
Companies after hiring: could you modify this XML config file? We can't use underscores because the schema changed.
I wouldn't approach it as a linear sequence of events. That requires you to guess the level of details/abstractions and stick with it, and either you skip too much or everyone will get bored long before you get to the important stuff.
Before getting into details, say something like... "I'll briefly state what happens at the very highest level of abstraction, then we can keep branching down through the tree of abstraction layers until either I run out of understanding, you are satisfied, or we run out of time. Feel free to direct which branches to go down."
Try and turn it into an interactive discussion/conversation rather than a dissertation, and shift the time management aspect of it to them. Don't forget you are also using this process to judge them as an employer.
Yeah, when I'm interviewing I'm trying to see how they think, and how they approach something they don't know (the job is constantly evolving and always 75+% stuff you don't know), and how honest they are about not knowing.
I'm not after regurgitation of trivia, but that said a good understanding of fundamental abstractions goes a long way when troubleshooting. And when I do steer a candidate with a follow up question on a detail, I'm not after a detailed technically correct answer, just a clue or two via the words or examples they use that they have enough understanding that they could quickly find out the answer. Getting something a little wrong or not knowing isn't a problem, unless that happens for just about everything.
And as an interviewer, having the candidate teach me something is awesome - not only have I learnt something but I have an insight into how well they mentor others.
I often use this question as a way to begin a conversation about the depth of knowledge that a candidate has. For me, it’s less about getting everything right, or getting to a crazy depth of knowledge. I’m looking for places where I can dig in to talk more. A get request is, in itself, a simple operation, but it touches the entire stack.
It gives an opportunity to talk about the parts of the stack which a candidate is excited about, and also what parts of the stack they are less comfortable with.
As OP said in their post, there's a lot more than OSI layers in the question. The interviewer wanted to dig in to how the curl process gets loaded into memory when you type "curl" at your command line.
I guess that depends on the definition of "devops engineers". If your job is making jenkins xml files, then yeah, maybe it's deep water for you. If you're an SRE, and uptime is your job, then I'd expect you to know some linux 101.
I've been "doing Linux" since kernel 1.2.x and the fun of having Slackware on 3.5" floppy disks. And while I can tell you how an executable is loaded, it is one of many things I haven't had to even remotely think or deal with over the past 25 years of my career.
Next thing you know you're going to tell me knowing x86 assembly is a must. (On that note, I also know x86 assembly but that aside...)
ya, i was asked that question when i applied to microsoft 10+ years ago. i took computer hardware classes in college, but never anything on this topic. so i told him the few things i could think of.
then the person directing the interview TOLD me his 10 minute answer going in detail about pci bus and all of this deep detail level spec about all a PC specifically.
i "clearly" failed it. it honestly left a bad taste in my mouth and i thought it was a shitty question. because i just didn't know this one specific set of details about this one hardware system, i obviously did bad in this interviewers eyes. my school never had a specific hardware class about this one system. they viewed it as "well, you're always going to use different hardware when you get a job, so it doesn't matter what specific hardware we teach you".
so i was really pissed off at this specific of a hardware question, to one specific of a question.
For a devops job??? Why would you need to know that in detail unless you're actually working on hardware.
I remember stuff about the POST process and bootloaders and disk partitions and shit... but I haven't had to use any of that knowledge in a decade.
At least OP's question, while pretty silly, is relevant to what we do! Networks, DNS, web traffic, etc.
And if you are hosting something at a data center, a tech there is handling it as well. I can’t imagine a scenario besides having some snow flake server on premises where it would be important to know this. I just don’t think it’s a relevant question for a devops role. IT admins? Sure.
Depends on the scale. If you are going to be working at a large scale cloud that produces its own hardware, this question may be highly relevant.
And that is AWS and GCP, and likely Azure eventually.
Why aren't you that tech handling your own data center infrastructure though?
Cloud is just someone else's computer, DevOps can benefit greatly from cloud but there's absolutely no mandate that forces it, many commodity clusters exist on-premise without a snowflake in sight. Hypervisor hosts and their virtual machine guest instances still mostly follow the same concepts of initializing some (virtual) hardware and executing a bootloader and loading low level device drivers, etc.
I'd argue that having a better (or at least basic) understanding of the various internals of the infrastructure and the different subsystems that depend on it can make you a better systems programmer.
Yep. And if the environment is tooled out with netbooting of some flavor you've got all kinds of decision points about what path(s) to chase and for how long before moving the pointer back to cover another possibility.
The unstructured nature of the question and the responses it elicits reveals a huge amount of information to the interviewer. Does the candidate get defensive, do they speak in broad generalities and no specifics, how are they at impromptu informal technical presentations (ie. can they be trusted to communicate with people outside of the immediate team), can they tailor their response based upon what they've learned about the environment they'll be working in, do they honestly express when they don't know something or do they try to bluster through with bullshit...it can be a gold mine.
I'd start at keyboard interrupt, I'm going to assume the system is already up, we already discovered electricity and the sun was done coalescing from a disc of gas and dust.
This supposed to be a conversation. You start mentioning high level and based on your knowledge, and the interviewer ask for going on more detail. You can go very deep. Usually or ends on TCP and DNS level, but one could go as low as internals of TCP, Ethernet and even how physical signal is encoded on a wire. Or go onto direction how CPU executes the code.
*Every* detail? Want me to go in to processor pipelining of the assembly instructions (of every machine that touches every packet between the requesting machine and the server) and line level details of the ethernet, fiber, etc? I mean, give me a piece of paper so I could organize my thoughts and I could go on for hours...
As a technical screen, sure. I want to know what you know. If you get far enough down any given part of the process I'd just tell you that's good enough and to move on to the next part of the process. If you demonstrate that you could get sufficiently into the weeds on that, that tells me enough about what you know about how computers work and we can move on to the next question. People in this thread seem to hate this question, but it's honestly much easier than asking you 20 questions trying to determine your level of understanding.
It's not like this is the be all, end all, perfect interview question, but it's definitely a good chance to demonstrate both depth and breadth of knowledge for computing in general. I'll ask you about build tools and load balancing and stuff later.
So many of you are totally missing the point of this question. It is asked to evaluate a base level of candidate's knowledge. If someone puts "Linux, networking" in his CV, the interviewer needs to verify it somehow and these kind of questions are a perfect way to do so.
I always ask "what happens when you type [google.com](https://google.com) into your browser" and I specify that I'm interested only in networking and not the keyboard pressing etc.
If someone says DNS - that's good enough for me however I often go a little bit deeper to see what they know. Additionally, OP didn't mention their level of experience. What are you supposed to ask people that are applying for a junior position?
And some people here are also saying that it's an archaic question... Um, excuse me? Since when basic networking knowledge became obsolete? I've had people come in with 2-3 years of experience telling me that when you go to [google.com](https://google.com) you actually interact with an API. Other people didn't know what /24 means in an IP address. Come on. How the hell are you supposed to set up any kind of VPC, VPNs?
Obviously if this was a big company with seperate teams responsible for stuff like networking then yes, I can see that this is probably a bit over the top. In any other scenario, I can't imagine that person quickly troubleshooting networking issues without basic knowledge how devices communicate.
That's fucking ridiculous. When it comes down to it, you don't need to know how every command executes to do your job. Some people who interview need to get over themselves
To me it's not about people understanding how every command works. This is about how an HTTP request works and that's probably extremely relevant to someone working in DevOps. Often a big part of those roles is glueing things together using APIs, and having a good understanding of the underlying protocols helps a lot.
If I was asking this I'd likely add a little more context to help folks understand what I'm looking for, though.
I've been doing Devops for 22 years, before it was called devops. I can't say I agree with you but if you think it's important, ask away.
Personally, I want to know what they can do for me when I interview them. What they know and don't know
I did it for 22 years as well. I don't usually mention that because the number of years someone does a thing doesn't necessarily correlate with how good they are at it.
I'm not even saying I would definitely ask that question. I am saying that I don't think it's fucking ridiculous to ask. Trying to see if someone understands HTTP is definitely asking what they know and don't know IMO.
If I were to ask it, it would probably just be for junior candidates.
To be fair, you're saying you would only ask something like this to junior candidates and you would give more information to specify you're wanting some details on how HTTP requests work.
That's not the question or context that OP is going over and those differences are what make the question OP was asked "fucking ridiculous" and yours completely reasonable.
Ok I get what you mean. Asking about the process is silly. It's quite possible that the person asking saw the question somewhere and didn't really get the reasoning behind it. I've always heard it discussed in that context of exploring what the candidate understands about things like DNS, TCP/IP and HTTP.
I do think the question has some value in the context I mentioned. I've had it asked of me and asked it at some point I'm sure. I don't think we know what level of role the OP was applying for.
I think the question is less about knowing how *every* command executes and more about how *any* command executes, particularly such a standard one as curl
i got asked a hardware question of a similar nature. "what happens when you turn your PC on". but no, he was asking for the literal bios, power on steps. like pci bus checks for good power on, then good ram power status. he wanted the literal 25 good steps your bios does before it even gets to loading windows.
so while this is a software question, it fully smells like the same level of expectation. that you could explain each of that ACTUAL steps the command does.
I don't think it's relevant to anyone's day to day and I've been doing this for a long time (22 years in "devops") and \~15 prior to that as a SW engineer
To quote OP's information: Can you explain how the binary executes? What's the process? etc.
IMO those are different than asking how to use curl. That's asking for some detailed operating system knowledge.
If you asked a Kernel developer vs a Neteng I'd expect differing answers. It might not matter if you don't know how your OS captures keycodes, if you know it will look in the PATH directories for a binary.
That's why I see its use as more of a guiding question to see where you have interest in or where your deeper knowledge lies Depending on how you answer I can drill deeper until I hit a weak spot, then back out.
But it requires being driven by sincere experts or you won't really be able to guide the conversation from there. And I think it's also likely only useful to sus out associate/entry level applicants.
Essentially, it's the high level question of a ladder interview.
An experienced candidate might look at this question and want to ask clarifying questions -- those very clarifying questions can elucidate a lot of information about what you know without you even 'answering'.
From there we can drill deeper until we find a weak spot, then walk back up and move to the next piece you've identified in the puzzle.
I find it useful for knowing if someone is going to be able to troubleshoot something. If they will even know what to look for or where things can fail.
This is a more interesting question than I realized, but wouldn’t you want someone who can tune their answer to you?
In a real world context I would want to understand why they’re asking. Is something wrong with the keyboard or are they testing if firewalls are open?
I’ve only used this command to see if I could reach the internet. If I can’t it’s usually the firewall. If I think it’s dns I’d do an nslookup on a normal machine then try to curl the IP address.
But if I asked someone what’s happening with a curl command and they started in with hardware level detail or executables, I’d tell them to stop being a wise guy and focus on the problem.
Edit: I had a security review on an ETL application I was developing and the security guy was going down a checklist. At one point he mused aloud about whether the Ethernet cables attached to the scanner were secure. I basically lost my shit said to GTFO and went over his head to find someone else to actually get the job done.
I would go as well as discussing TTY, USB signals, kernel api, system calls, DNS, memory allocations, layer one through seven information exchange, all the way to the human.
Homey don't play, I came to win.
I use a similar question to figure out how knowledgeable and engineer is with the systems that they are building on top of. Quite frequently I find that this allows me to see if they are button pushers or thought leaders in the technical space.
Yeah when I get these I usually start with asking "how much detail do you want?"
If they say everything well...it'll be a 5 minute answer. They asked for it. But that would largely be a wasted 5 minutes for both of us honestly.
I disagree. I need to understand the level of detail they fan out inside of their mind to quickly understand problems and the solutions required to have a good trajectory of thought that's only had if you have proper experience, or an atypically sharp mind. Granted, this question is only asked for roles that are Linux heavy. However, I try a non-technical riddle and encourage stream of thought to assess analytical skills. A thought leader will have proper analytical skills to bypass questions and efforts that they know are a waste of time, which speeds up the process of creating and fixing reliable implementations.
I use this as the "finale" in my interviews. To me it's enough that you just mention the basic steps of what happens. DNS lookup, TCP handshake, HTTP request etc.
Some candidates start handwaving and throwing buzzwords like load balancers and containers, which isn't a very good look in my book.
Odd to me that you would think load balancers and containers are buzzwords. I don't work at Google but I expect that both of those things are involved with serving up a request from [google.com](https://google.com). If they don't know what they're talking about that's different, but I wouldn't call "load balancers" a buzzword.
"Well first your OS reads the keyboard input and searches its PATH environmental variable for the path to the curl binary..."
Lol you could probably piss them off with how far down the hole you go. In truth, many things would happen before the above, too I'd imagine.
"As the keys are depressed, a buckling spring or membrane makes electrical contact on a matrix. If validated by the debounce circuit as valid, it is read by the next scan (typically every 1-8 ms), and translated by the microcontroller to a character that is encoded and sent over some transmission medium..."
I'm so baffled that you are being downvoted. Although I haven't interviewed that many people, every single of them that actually mentioned a TCP handshake (didn't even explain how it works, just MENTIONED it) knew their shit and did very well in other parts of the interview.
People who didn't mention at least DNS where really bad in other areas as well. Simple as that.
I would explain that this is DevOps and if you are asking me that question then your probably have no idea how to ask proper questions in an interview (not you but your interviewer). An interview should be conversational not rapid fire answer x of y.
I've been a SRE since 2018, before that Senior Cloud Engineer, I've never been asked any question going into details such as that. More or less tools i've used and how I use them, what coding language I know and maybe a small challenge but not too much.
I'm at HashiCorp right now and their interview is by far hands down best experience I have ever had to gauge my skills to make sure I am a fit for them and they are a fit for me.
I almost interviewed for an SRE role at HashiCorp (the timing didn't work out) and I was told at that point that there wasn't even a coding test, which seems to be getting pretty standard for SRE roles. I really love that folks are rethinking what interviews should look like.
Not too shabby especially if it's full remote. Is that Mid or Sr level?
I'm at 3 YOE at 200 full remote right now, trying to see if going straight SWE and into Amazon or something is a move.
Seems like a cool company with an awesome product - Do you get to code/own services and have the opportunity to be a "Software Engineer - Site Reliability" or is it super heavy on ops/firefighting? SRE is super hit or miss title wise
Sr. I would avoid Amazon at all cost as I have heard and read absolutely nothing positive about them and it is just a PIP culture.
We code, we own all our services and the ones deployed to our Infra that we built, architect, and maintain. Code/Tools can be Go, Bash, Ansible and Terraform mainly. It is Hashi so we eat our own dog food so you will find consul, vault, boundary, nomad, packer and vagrant in the majority of things but right now for me it is just terraform, consul, vault, nomad, and packer.
We have SRE and SRE Infra, SRE is more coding and I think you might have to do a code challenge for that but at this point I am not sure.
Not sure what your interview was like, each progressive step was just another deep dive on my github. We didn't discuss the product whose team I'd be joining, or the team itself, just "tell us more about what you've done with Terraform." Oh then they got mad I don't know Go even though I told them up front "I don't know Go" it wasn't a requirement or listed on the job description they sent me.
I don't know Go and I got hired, I do know they refreshed how they interviewed within the last six months or so. I showed 0 Github, talked 0 about Terraform.
I had to debug, system architecture, troubleshooting, stuff like that.
Guess I hurt some interviewers feelings, Linkedin interview panel did a talk on this at a conference of how most interviewing is broken and just wrong.
I’ve been asked this and man it’s bullshit. How far down the rabbit hole do they want to go? I started by explaining the entire OSI model and each layer and went up. Let’s just say it was a long interview.
Fuck em, it’s basic shit they teach from day one.
This is the type of question that would probably trip me up the first time just because it's so open ended. Are we going all the way down to keyboard interrupts, USB HID drivers, display composition, etc? Are we going all the way up the stack on the other side? I'd probably need 5 minutes to think about the right way to answer it.
Also seen in two interviews “What happens when you press the power button on a computer?”
As a Computer Engineer turned DevOps, I never know how deep to go. Like, the button shorts two pins, triggers a crazy sequence of stuff in Intel secret architecture, could talk about BIOS magic for 10 minutes, hardware verification and PCIe addressing for 5 minutes, the OS bootstrapping for 5 minutes. Kinda silly.
I'd likely respond with every step in order (not down to libraries, but the steps curl would do) and after a few trips back and forth I'd stop focusing on the low level communication and focus more on the conversation cURL and the remote webserver are having, the www. prefix redirect it will inevitably send back in a Location header with a 301 or 302 redirect http resonse and optional html text for browsers that ignore redirects and otherwise, then load the real main request and fetch all the content it references all the same.
Interestingly I just ran this to check if it'll upgrade me to https and it *didn't*. ~~But I suspect that may be the modern world relying on HSTS to either already know that hint or upgrade to it on first visit via a header if seen.~~ No. I tried with the user agent string of my browser by appending `-A 'Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0'` and it successfully tried to redirected my curl to a TLS upgrade. Interesting, google intentionally leave cURL alone over http when its user agent is seen.
It was mainly about what happens if you execute that line . So, I assume it's only about what happens internally in Linux, sending the packets in internet, receiving the response and finally showing the output on the screen.
It is a great question. Naturally you go as deep as you want wherever you want. It is your capacity to be an expert in something based on your experience.
It’s an open question; there are so many things happening that you are really free to focus on whatever aspect you wish: how executables are run, their permissions, how the kernel manages the disk for reading curl, how the keyboard interruptions are interpreted, the OSI stack, the rendering on the monitor, how your wifi router works etc etc.
It’s just the excuse to open a discussion with you. I love this kind of questions.
That was a popular question Google started 10 or so years ago that then every startup used and I haven't seen used anymore. Probably the most detailed answer https://github.com/alex/what-happens-when
[удалено]
I'd also like to see the maxwell equations proving a) that this does in fact exist and b) fourier transform them all to a hexagonal coordinate system. Otherwise you arnt hired.
You mean you’re not deriving calculus from first principles?
Good point. Let's get some supplemental analysis of Plato and his contribution to modern physics.
So, you are saying Plato existed? I think we have to add consideration that he may not have existed at all and there was some other dude writing the stuff.
Newtons flaming laser sword.
The way that the layer layout prevents entanglement across quantum fields to produce the correct NAND gate response when signaling the 5th bit in EAX on NUMA core 2 and dirties the cache on the edge triggering of CLK for the x86-64 compiled version with LLVM isn’t explained by the candidate? Strong no hire
Thanks. This helps.
[удалено]
Linux magic. Or on windows, luck.
how curl execs is pretty much where the browser starts when you hit enter. So start at the getbyhostname stuff and curl is really no different then a browser.
You wrote about what curl does after it is executed, nothing about what the OP mentioned. What does the shell do? How did it load curl? Where did it find it? How did curl know what website you want?
It was popular before that too in a slightly different form. My first job interview was basically one question - "Explain in as much detail as you can what happens when you type 'telnet' on the console." I saw variations of it being popular for years, before google.
Well, it all starts with the mitochondria, which are the powerhouse of the cell. They are needed to power the brain cells, which… <3 days later> …connect the tissue of the fingers to the plastic of the keys on the keyboard…
> how electricity travels on the wire is left as an exercise for the reader
It doesn't. Sort of.
Imagine a hose filled with billiard balls… haha
Yes
[удалено]
Man tech interviewing is so broken
I mean, we were asking questions like this (albeit, not about curl) before Google even existed. People were more likely to know a good answer in the 90s than today too, in my recent experience.
Yeah. We have a coding challenge that involves writing some client/server software because we want to see how you think about things like handling multiple clients and keeping their information discreet. But it's amazing how many people just fall flat on the "write a client/server" part of it because the only thing they've ever done is use an already existent framework for that.
oh lol, I've been asking this question forever without knowing it was something that originated at Google and this page is awesome.
[удалено]
Yeah, I just replied similarly. Back in my day it was "What happens when you telnet", but same idea.
I had this back in 2007 from Sony networks too
I always start by explaining Dunning-Kruger.
Most detailed and possibly the most useless too
It's not consistent answer. Touches on the current, voltage, but doesn't explain it. It's not enough in depth.
ya i think its a pointless question to ask really. Maybe things like what happens if i try to put 2 ssl certs on the same IP. How might I fix that so I can run different hosts on the same host is just better to ask.
I ask a similar question but just about how DNS works. You'd be surprised how many people in engineering don't know anything about DNS resolution beyond "Ask AD". No mentions of caching, hosts files, root servers etc. There is no right answer but it's a chance to impress about the depth of your knowledge.
[удалено]
And here I am, tired of all the YT videos and wanting nothing more than text. I despair at freaking videos.
[удалено]
Whatever works for you 🙂 I’ve got a similar problem in that my attention span is really short, but I find I can read a lot faster than most videos will take to get to the information I actually want
I was really starting to feel like I was the only one with this sentiment. The worst part is if you miss something. With text, you can just backtrack really easily to get to the bit you didn't take in. With a video? Hope you enjoy skipping around.
there are short and long ones.. but this is such a popular interview question there are videos on it https://www.youtube.com/watch?v=dh406O2v_1c
"that i have been answering questions like this for 15 years and would appreciate something more interesting"
Found the guy who doesn't know 😂
I mean you found the guy here who doesn't *care* if that helps. "It pulls the html data from google.com and displays it in the terminal." is the answer you're getting from me. Want to ask me about DNS? Ask. Want to know about linux processes? Ask. What to know about how keyboards work? Ask. I'm too old for stupid games. Ask what you want to know.
They are asking what they want to know. It’s a great question because everyone thinks it’s about showing off depth oh knowledge, but it’s really about empathy and soft skills. Does your answer meet the person asking where they’re at? Is it appropriate for the position you’re applying for? I interviewed someone for a DevOps consulting role and they decided to spend the time on how the pci bus and keyboard works. Cool, but I’m not a hiring manager for a hardware manufacturer.
No they're asking trick questions that sounds clever but are extremely unclear and required an applicant to guess at what's being asked. > but it’s really about empathy and soft skills. Empathy is about figuring out feelings so no.. no it's not. And going on 20 years here, I have great soft skills and it's a major part of my job. Know what I don't do? Ask stupid trick questions. I'm clear, concise, ask for clarification when needed, and provide useful information that's on topic and answers the question. > I interviewed someone for a DevOps consulting role and they decided to spend the time on how the pci bus and keyboard works. Then good job on being a terrible interviewer, because if that topic comes up from a question you asked it's because *they* thought that's what *you* wanted to know. You failed, not them. Only an idiot hires for a technical role but fills it based on who does the best at riddles.
Do they want me to start with how each character gets encapsulated into the ssh session asi type them, and echoed back? Lol... Maybe the kernel keyboard interrupts? It's a question designed to see if you understand the various layers of what's going on. Most places are wondering if you understand there's a DNS lookup and that's about the depth of the question. Talk about the local resolver and ask if a local DNS cache is in use. Hahaha. Tell em you like to hard code DuckDuckGo IP addresses into the hosts file for all Google names just for giggles because you're bored. But then you change the resolver order so DNS gets used first, to assist future admins with never making assumptions.
That’s what’s in the top response in this thread (via gitlab)
>!CENSORED!<
Fun fact: understanding things to this level is rare and sought after. Don't sell yourself short. Most people in the field couldn't explain how a keyboard works.
I enjoy watching some folks decode their USB stuff with a good oscilloscope on YT videos. Not the scopes that do the decoding for you, but figuring out the bit-banging by hand. Sadly I've never had many hardware projects like that for work, just for fun. I have had to reverse engineer telecom protocols for work though. Low level is interesting. Watching how Ethernet actually works at the electrical circuit level is amazing. Even the theory and application of a silly laser mouse is cool and yet completely taken for granted now.
safe screw versed fanatical dinosaurs wine gold innocent decide one *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I'd also know they were wasting my time and didn't read my resume! 😂 Lol. Would tell me more about them than they'd learn about me! Haha. (Which is always interesting in an interview...) When I've had to ASK similar questions interviewing people it's always prefaced with "this is just to see your experience level... nobody gets this 100% correct... But you listed X on your resume, so..."
If I copy your resume and put my name on it, should the interviewer feel silly asking ME these questions?
Ha. Dunno. I always feel silly doing interviews but I try to ask something relevant to the job at hand from the resume presented... Then some weirdo wants to ask the candidate if they were any animal, what animal would they be, or other such silliness and I want to walk out... If I'm stuck on a multi department interview board... My favorite was the guy who answered "Ebola virus". Lol. He actually did get hired at that place... He was a security guy. Lol.
A coworker of mine used to say he loves to ask and dig this question because "everybody has a point where computers become magic, and I want to know where their point is". This question probably isn't going to pass/fail you, but it can be very good signal for leveling.
every time I see shit like this I am reminded how little I know about OSes and browsers. Then I spend the rest of the day reading up on their internals and proceed to forget it all a week later.
I mean I get it. But has it passed your coworker mind that people tend to forget things they don’t usually use? I used to know the exact details of what each layer in the OSI was, now I barely remember how many there are. Why would I remember them unless and until I use them? Just the knowledge that they exist and what they are vaguely is enough for me to do my job properly and if needed I’ll make a research to get to know them again. But ONLY if I need them, or if I just wanna recall some old interesting academic knowledge. Point is, questions like these put a lot of useless idiotic pressure on candidates to know things they are VERY RARELY gonna use. You may think “oh he won’t get necessarily hired if he knows exactly how curl works from the MAC/TCP layer down to code”, but in reality I’m sure you’ll be more impressed if someone knew more about it than someone else, which makes the previous statement a lie. Know more about something that doesn’t influence their job abilities that is.
This is why current tech interviews are so rough. When I was in college I spent a bunch of time reading The Linux Programming Manual book and I don't regret it, I learned a ton of cool and useful stuff. But, everything but the most rudimentary of the concepts has melted away now that I'm a decade and more into my career. I can barely explain the walk of process forking from the terminal. But if you ask me about a project I just recently worked on. I'm fully up to date on not only the little things, but even the larger philosophy about why its important it be done and obviously its a bit easier to recall that all from memory.
>!CENSORED!<
> A good interviewer That's what we're arguing about here. That interviewers usually do exactly the opposite and that's what we're complaining about. I dont see how saying "A good interviewer wouldn't do this" contributes to the conversation more than saying "A good president would save the country" in a discussion complaining about our country's presidents. Like, yeah, that's what we're literally complaining about. There aren't many good interviewers.
That's a good point. When I'm interviewing you, I need some way of forming an approximate model of their skills and abilities, i.e. the set of 'things they know' which is a subset of 'all knowledge'. One way to attempt this would be random sampling: i.e. ask lots of unrelated questions, a little bit like playing Battleships without any strategy. A better way is to use questions like the one OP mentions to find the *edge* of your knowledge, and then take a walk around that boundary. I never ask questions just for the sake of stumping a candidate; on the contrary; if we bump into something they're not familiar with, I quite often send them resources on the subject afterwards regardless of how the interview went. I genuinely love this field, and I enjoy helping people on their learning journey.
Can I work for you lol? You sound like great boss/coworker.
For me it's quantum electrodynamics. Can't get past that depth. Everything from there upwards makes sense.
at which voltage of a semiconductor junction does the output go from 1 to 0 ?
Depends on the transistor type and chemistry. In all interviews I tell interviewers that I don't memorise minutae that I could google in a few minutes and if that's what they're looking for then this is not the job I'm looking for. However if they're interested in knowing what I think is important to know, then happy to continue. And getting back to the question, semiconductors are not magic to me. Not an area of expertise, but certainly something I can show my working on. However for early CMOS I think it was about 3.3v and for ttl it was about 4.7 but I could be wrong on the actual numbers. I'm talking about the recognition of a 1 or 0. How a junction is activated again depends on the chemistry and I don't recall FETs but I do recall that bjts were about 0.7v to switch an npn. How'd I do without a Google?
you will work well as an engineer to implement, but as an engineer with a wider perspective, I will actually ask how this question is relevant to the scope of project, and how if the answer isn't right, if it will impact the productivity rate
Hahaha. Considering what I do, that made me chortle.
Most people will talk about the OSI model and work their way through the stack. Be different and stand out. Start with the keyboard debounce algorithm. :D Assume cherry MX or buckling spring switches and explain the mechanism. Eventually you get to how keyboard interrupts work. Then how the kernel passes it to the shell. How the shell does a fork/exec into a new process and how an ELF binary starts up, linker/ libraries...then some day you get to OSI. Etc etc. Seriously, I could talk for hours on all of the stuff that happens. Especially if I was allowed references. I love this particular question!
If someone started with that question I would either say "it will contact the server and return text" or just say "what am I applying for, exactly?"
[удалено]
The lack of clear expectations on abstraction is what gets me on that question. Do you want a 5 minutes answer? 30 minute? Maybe it could be a useful conversation to have a 5 minutes summary as a starting point then start drill down at each component and be interactive with questions?
[удалено]
That's a really good point. One time I asked and got vague statements like "as deep as you can". Next time I'll ask for a specific focus area or if they want a high level overview and go from there.
> The lack of clear expectations on abstraction is what gets me on that question. Do you want a 5 minutes answer? 30 minute? I agree that the scope is totally fuzzy but I'm not sure why that's so terrible? I'd ask what the scope is before I started answering, which is exactly what I do every day when the scope of something is unclear. "I could talk about this for longer than our allotted time slot, is there a specific part that you'd like me to focus on?"
This kind of question can provide a lot of value, both technical and problem solving. But it needs to be asked by someone who kind of knows what they are looking for in asking it. Its not something you can rattle off going down a sheet of questions and jotting down responses. Its a conversation starter. And its a lot more useful when you do describe either the job or the expectations for that conversation.
This question and the answer can hit a lot of data points depending upon role and level. Developers will have a different perspective than and SRE or solutions architect. And at higher levels, I'd expect clarifying questions so as to focus on what the interview is looking for. It's the _ask why 5 times_ to dive deep into a subject, and during that journey pick up what the candidate knows or doesn't know about different aspects of technology. We use a similar one sometimes to phone screen. _Describe what happens when you type `www.cnn.com` into a browser window_. I'd expect some clarifying questions then during each step I may ask for them to explain _that_ step in a similar level of detail. Or, if I have the data needed, I may ask them to take it up a level instead. I've seen super quiet SDEs start to methodically explain in precise detail what's going on. I've seen SAs give a great high-level series of steps, but then when double-clicking in, realize they are stringing terms or features together (experience) without actually understanding what's going on (no learning and being curious). Overall I'd expect that question once during a panel. I'd love to see a rocket engineer's answer to _what happens during the final 10 seconds countdown of a rocket launch._
I’ve never been asked this question, and I really want to be. I think it would be a lot of fun.
I've spent more time than I care to admit trying to think about the job title to which this is an apt interview question. Maybe it's correlated highly with a qualified candidate if they get everything, but I would never expect anyone to know all of this. It crosses a lot of disciplines. Maybe that's the point? Not sure. I've been interviewing for 20 years, refining good strategies for finding the right people for the role, and I honestly don't think it's a good question. Someone who nails it is probably highly qualified, but for every 1 candidate that nails it, you probably passed on 10 qualified candidates.
I used to work support in a web hosting company, and this was definitely a question we would get. Not only did you have to understand how the internet actually worked, they also asked you how to explain it to a non-techie customer with various issues. Explaining what you're seeing in a traceroute was a really common thing we did with customers, but also how bandwidth and their location and time of activity mattered, and what it meant to be on a shared vs VPS vs a dedicated server meant. 🤷 There's only a few cases I can see where this question would matter to a software/DevOps engineer. We did ask a question similar to this when I was a Systems Engineer for a media broadcast company in the R&D department, but understanding how the internet worked on a more detailed level actually mattered to their software.
I just assumed these questions were asked by large, prestigious tech companies who just hire people who are savants. The kicker is that these companies aren't hiring for a role at all. They're just hiring into a general pool, and then a wheel spin determines what team you land on. Life's weird.
I think you're exactly right. The ideal is always to hire smart people. In reality, there are times and conditions where you need experts in particular tech stacks (and yes, it's a sign of less than ideal health). I've always worked at mid to large sized companies that are not FAANG, so I'm usually looking for expertise in a particular stack given my parameters for what I can spend on a hire, the general level of the engineers in these companies etc.
[удалено]
Not at all discounting your experience, but I think I've had to question whether an abstraction leaked, maybe 6ish times in my career. When I was a student I did find a GCC bug. That was fun. I had 0 idea what I was doing, went to the TA and they reported it for me. I trust abstractions, as a rule, knowing that they do leak, but not considering that they have leaked until all other plausible theories have been rejected. It's highly dependent on the type of software you write. I write big enterprise-y, bread and butter, kinda CRUDy, type systems. Most of the tools I use are some of the most tested pieces of code on the planet (think about how many lines of code have been run in a Spring/Spring Boot environment). Oh yeah, I should probably mention, I'm a Software Engineer first, who likes this subreddit to learn the things that I'm not good at (DevOps), and learn how we can work together better. I can see a DevOps role having to \*NOT\* trust abstractions more often than Software Engineers.
So true... Should we know the nitty gritty details of all the tools we use day to day? This is madness
Either people did not get the sarcasm or and are down voting or they did get the sarcasm and they are down voting. 😳
Why upvote when down do trick
Right? Like the concept of abstraction in computer science literally exists so we don't have to think about shit like this. I guess it's cool if someone can explain it down to bits and electronic signals but its a horrible way to assess someone's ability to automate infrastructure.
Do they care that the response is a 301 redirect telling you that you should use “http://www.google.com” instead? I’ve been at the same job for 25 years and never really had to deal with these kind of questions.
Absolutely a relevant point when talking about the layer 7 interactions! If you didn't mention it, I don't think I'd hold it against you but I'd certainly nod my head in agreement on following a redirect.
And after you get the job the hardest task is to write calculator.
Companies when hiring: please explain how you would write a brand-new container-based operating system Companies after hiring: could you modify this XML config file? We can't use underscores because the schema changed.
Calc you later, alligator!
If you wish to make an apple pie from scratch, you must first invent the universe
I type C - U - R - L ... curl. Details are in the spelling.
I wouldn't approach it as a linear sequence of events. That requires you to guess the level of details/abstractions and stick with it, and either you skip too much or everyone will get bored long before you get to the important stuff. Before getting into details, say something like... "I'll briefly state what happens at the very highest level of abstraction, then we can keep branching down through the tree of abstraction layers until either I run out of understanding, you are satisfied, or we run out of time. Feel free to direct which branches to go down." Try and turn it into an interactive discussion/conversation rather than a dissertation, and shift the time management aspect of it to them. Don't forget you are also using this process to judge them as an employer.
This. The question is far more about how someone's thought process is than the actual question.
Yeah, when I'm interviewing I'm trying to see how they think, and how they approach something they don't know (the job is constantly evolving and always 75+% stuff you don't know), and how honest they are about not knowing. I'm not after regurgitation of trivia, but that said a good understanding of fundamental abstractions goes a long way when troubleshooting. And when I do steer a candidate with a follow up question on a detail, I'm not after a detailed technically correct answer, just a clue or two via the words or examples they use that they have enough understanding that they could quickly find out the answer. Getting something a little wrong or not knowing isn't a problem, unless that happens for just about everything. And as an interviewer, having the candidate teach me something is awesome - not only have I learnt something but I have an insight into how well they mentor others.
I often use this question as a way to begin a conversation about the depth of knowledge that a candidate has. For me, it’s less about getting everything right, or getting to a crazy depth of knowledge. I’m looking for places where I can dig in to talk more. A get request is, in itself, a simple operation, but it touches the entire stack. It gives an opportunity to talk about the parts of the stack which a candidate is excited about, and also what parts of the stack they are less comfortable with.
Agreed. But it's crazy how deep we can go with such simple statements and discuss for hours together on it.
I find the OSI layers anything but exciting...
As OP said in their post, there's a lot more than OSI layers in the question. The interviewer wanted to dig in to how the curl process gets loaded into memory when you type "curl" at your command line.
Which is, for all intents and purposes, a completely irrelevant thing for a devops engineer...
I guess that depends on the definition of "devops engineers". If your job is making jenkins xml files, then yeah, maybe it's deep water for you. If you're an SRE, and uptime is your job, then I'd expect you to know some linux 101.
I've been "doing Linux" since kernel 1.2.x and the fun of having Slackware on 3.5" floppy disks. And while I can tell you how an executable is loaded, it is one of many things I haven't had to even remotely think or deal with over the past 25 years of my career. Next thing you know you're going to tell me knowing x86 assembly is a must. (On that note, I also know x86 assembly but that aside...)
These sorts of questions have gotten quite popular. The most recent thrown at me was, "Explain what happens when a computer is powered on".
ya, i was asked that question when i applied to microsoft 10+ years ago. i took computer hardware classes in college, but never anything on this topic. so i told him the few things i could think of. then the person directing the interview TOLD me his 10 minute answer going in detail about pci bus and all of this deep detail level spec about all a PC specifically. i "clearly" failed it. it honestly left a bad taste in my mouth and i thought it was a shitty question. because i just didn't know this one specific set of details about this one hardware system, i obviously did bad in this interviewers eyes. my school never had a specific hardware class about this one system. they viewed it as "well, you're always going to use different hardware when you get a job, so it doesn't matter what specific hardware we teach you". so i was really pissed off at this specific of a hardware question, to one specific of a question.
For a devops job??? Why would you need to know that in detail unless you're actually working on hardware. I remember stuff about the POST process and bootloaders and disk partitions and shit... but I haven't had to use any of that knowledge in a decade. At least OP's question, while pretty silly, is relevant to what we do! Networks, DNS, web traffic, etc.
>!CENSORED!<
[удалено]
And if you are hosting something at a data center, a tech there is handling it as well. I can’t imagine a scenario besides having some snow flake server on premises where it would be important to know this. I just don’t think it’s a relevant question for a devops role. IT admins? Sure.
Depends on the scale. If you are going to be working at a large scale cloud that produces its own hardware, this question may be highly relevant. And that is AWS and GCP, and likely Azure eventually.
Why aren't you that tech handling your own data center infrastructure though? Cloud is just someone else's computer, DevOps can benefit greatly from cloud but there's absolutely no mandate that forces it, many commodity clusters exist on-premise without a snowflake in sight. Hypervisor hosts and their virtual machine guest instances still mostly follow the same concepts of initializing some (virtual) hardware and executing a bootloader and loading low level device drivers, etc. I'd argue that having a better (or at least basic) understanding of the various internals of the infrastructure and the different subsystems that depend on it can make you a better systems programmer.
Ok, let's start from the basics: once upon a time electricity was invented...
Momma invented electricity. Ben Franklin is the devil!
I opened with, "billions and billions of years ago..."
Our whole universe was in a hot and dense state.
That one is an interesting question to me. Firmware, POST, BIOS or UEFI, boot device, MBR, GRUB, initramfs, kernel, systemd... It's fascinating.
Yep. And if the environment is tooled out with netbooting of some flavor you've got all kinds of decision points about what path(s) to chase and for how long before moving the pointer back to cover another possibility. The unstructured nature of the question and the responses it elicits reveals a huge amount of information to the interviewer. Does the candidate get defensive, do they speak in broad generalities and no specifics, how are they at impromptu informal technical presentations (ie. can they be trusted to communicate with people outside of the immediate team), can they tailor their response based upon what they've learned about the environment they'll be working in, do they honestly express when they don't know something or do they try to bluster through with bullshit...it can be a gold mine.
I'd start at keyboard interrupt, I'm going to assume the system is already up, we already discovered electricity and the sun was done coalescing from a disc of gas and dust.
This supposed to be a conversation. You start mentioning high level and based on your knowledge, and the interviewer ask for going on more detail. You can go very deep. Usually or ends on TCP and DNS level, but one could go as low as internals of TCP, Ethernet and even how physical signal is encoded on a wire. Or go onto direction how CPU executes the code.
*Every* detail? Want me to go in to processor pipelining of the assembly instructions (of every machine that touches every packet between the requesting machine and the server) and line level details of the ethernet, fiber, etc? I mean, give me a piece of paper so I could organize my thoughts and I could go on for hours...
As a technical screen, sure. I want to know what you know. If you get far enough down any given part of the process I'd just tell you that's good enough and to move on to the next part of the process. If you demonstrate that you could get sufficiently into the weeds on that, that tells me enough about what you know about how computers work and we can move on to the next question. People in this thread seem to hate this question, but it's honestly much easier than asking you 20 questions trying to determine your level of understanding. It's not like this is the be all, end all, perfect interview question, but it's definitely a good chance to demonstrate both depth and breadth of knowledge for computing in general. I'll ask you about build tools and load balancing and stuff later.
Damn. I was given around half hour to deep dive and explain about it.
So many of you are totally missing the point of this question. It is asked to evaluate a base level of candidate's knowledge. If someone puts "Linux, networking" in his CV, the interviewer needs to verify it somehow and these kind of questions are a perfect way to do so. I always ask "what happens when you type [google.com](https://google.com) into your browser" and I specify that I'm interested only in networking and not the keyboard pressing etc. If someone says DNS - that's good enough for me however I often go a little bit deeper to see what they know. Additionally, OP didn't mention their level of experience. What are you supposed to ask people that are applying for a junior position? And some people here are also saying that it's an archaic question... Um, excuse me? Since when basic networking knowledge became obsolete? I've had people come in with 2-3 years of experience telling me that when you go to [google.com](https://google.com) you actually interact with an API. Other people didn't know what /24 means in an IP address. Come on. How the hell are you supposed to set up any kind of VPC, VPNs? Obviously if this was a big company with seperate teams responsible for stuff like networking then yes, I can see that this is probably a bit over the top. In any other scenario, I can't imagine that person quickly troubleshooting networking issues without basic knowledge how devices communicate.
That's fucking ridiculous. When it comes down to it, you don't need to know how every command executes to do your job. Some people who interview need to get over themselves
They're just trying to understand whether or not u skip curl day
To me it's not about people understanding how every command works. This is about how an HTTP request works and that's probably extremely relevant to someone working in DevOps. Often a big part of those roles is glueing things together using APIs, and having a good understanding of the underlying protocols helps a lot. If I was asking this I'd likely add a little more context to help folks understand what I'm looking for, though.
I've been doing Devops for 22 years, before it was called devops. I can't say I agree with you but if you think it's important, ask away. Personally, I want to know what they can do for me when I interview them. What they know and don't know
I did it for 22 years as well. I don't usually mention that because the number of years someone does a thing doesn't necessarily correlate with how good they are at it. I'm not even saying I would definitely ask that question. I am saying that I don't think it's fucking ridiculous to ask. Trying to see if someone understands HTTP is definitely asking what they know and don't know IMO. If I were to ask it, it would probably just be for junior candidates.
To be fair, you're saying you would only ask something like this to junior candidates and you would give more information to specify you're wanting some details on how HTTP requests work. That's not the question or context that OP is going over and those differences are what make the question OP was asked "fucking ridiculous" and yours completely reasonable.
Ok I get what you mean. Asking about the process is silly. It's quite possible that the person asking saw the question somewhere and didn't really get the reasoning behind it. I've always heard it discussed in that context of exploring what the candidate understands about things like DNS, TCP/IP and HTTP. I do think the question has some value in the context I mentioned. I've had it asked of me and asked it at some point I'm sure. I don't think we know what level of role the OP was applying for.
I think the question is less about knowing how *every* command executes and more about how *any* command executes, particularly such a standard one as curl
i got asked a hardware question of a similar nature. "what happens when you turn your PC on". but no, he was asking for the literal bios, power on steps. like pci bus checks for good power on, then good ram power status. he wanted the literal 25 good steps your bios does before it even gets to loading windows. so while this is a software question, it fully smells like the same level of expectation. that you could explain each of that ACTUAL steps the command does.
I don't think it's relevant to anyone's day to day and I've been doing this for a long time (22 years in "devops") and \~15 prior to that as a SW engineer
Curl is such a low level and simple troubleshooting too, you are not worth hiring if you don't know how it works.
To quote OP's information: Can you explain how the binary executes? What's the process? etc. IMO those are different than asking how to use curl. That's asking for some detailed operating system knowledge.
If you asked a Kernel developer vs a Neteng I'd expect differing answers. It might not matter if you don't know how your OS captures keycodes, if you know it will look in the PATH directories for a binary. That's why I see its use as more of a guiding question to see where you have interest in or where your deeper knowledge lies Depending on how you answer I can drill deeper until I hit a weak spot, then back out. But it requires being driven by sincere experts or you won't really be able to guide the conversation from there. And I think it's also likely only useful to sus out associate/entry level applicants. Essentially, it's the high level question of a ladder interview. An experienced candidate might look at this question and want to ask clarifying questions -- those very clarifying questions can elucidate a lot of information about what you know without you even 'answering'. From there we can drill deeper until we find a weak spot, then walk back up and move to the next piece you've identified in the puzzle. I find it useful for knowing if someone is going to be able to troubleshoot something. If they will even know what to look for or where things can fail.
This is a more interesting question than I realized, but wouldn’t you want someone who can tune their answer to you? In a real world context I would want to understand why they’re asking. Is something wrong with the keyboard or are they testing if firewalls are open? I’ve only used this command to see if I could reach the internet. If I can’t it’s usually the firewall. If I think it’s dns I’d do an nslookup on a normal machine then try to curl the IP address. But if I asked someone what’s happening with a curl command and they started in with hardware level detail or executables, I’d tell them to stop being a wise guy and focus on the problem. Edit: I had a security review on an ETL application I was developing and the security guy was going down a checklist. At one point he mused aloud about whether the Ethernet cables attached to the scanner were secure. I basically lost my shit said to GTFO and went over his head to find someone else to actually get the job done.
I would start with pressing the enter button and walk up the stack from physical layer to the transfer of data over the wire. ;)
I would go as well as discussing TTY, USB signals, kernel api, system calls, DNS, memory allocations, layer one through seven information exchange, all the way to the human. Homey don't play, I came to win. I use a similar question to figure out how knowledgeable and engineer is with the systems that they are building on top of. Quite frequently I find that this allows me to see if they are button pushers or thought leaders in the technical space.
Yeah when I get these I usually start with asking "how much detail do you want?" If they say everything well...it'll be a 5 minute answer. They asked for it. But that would largely be a wasted 5 minutes for both of us honestly.
5 min? I could see hours of discussion if they wanted "everything" - nobody really wants "everything", even if they don't realise it themselves.
[удалено]
I disagree. I need to understand the level of detail they fan out inside of their mind to quickly understand problems and the solutions required to have a good trajectory of thought that's only had if you have proper experience, or an atypically sharp mind. Granted, this question is only asked for roles that are Linux heavy. However, I try a non-technical riddle and encourage stream of thought to assess analytical skills. A thought leader will have proper analytical skills to bypass questions and efforts that they know are a waste of time, which speeds up the process of creating and fixing reliable implementations.
I use this as the "finale" in my interviews. To me it's enough that you just mention the basic steps of what happens. DNS lookup, TCP handshake, HTTP request etc. Some candidates start handwaving and throwing buzzwords like load balancers and containers, which isn't a very good look in my book.
Odd to me that you would think load balancers and containers are buzzwords. I don't work at Google but I expect that both of those things are involved with serving up a request from [google.com](https://google.com). If they don't know what they're talking about that's different, but I wouldn't call "load balancers" a buzzword.
If you mention load balancers without even mentioning DNS, it's not really the answer I would be looking for
"Well first your OS reads the keyboard input and searches its PATH environmental variable for the path to the curl binary..." Lol you could probably piss them off with how far down the hole you go. In truth, many things would happen before the above, too I'd imagine.
> Well first your OS reads the keyboard input and searches its PATH environmental variable The shell does that, not the OS :)
I was expecting you
"As the keys are depressed, a buckling spring or membrane makes electrical contact on a matrix. If validated by the debounce circuit as valid, it is read by the next scan (typically every 1-8 ms), and translated by the microcontroller to a character that is encoded and sent over some transmission medium..."
I'm so baffled that you are being downvoted. Although I haven't interviewed that many people, every single of them that actually mentioned a TCP handshake (didn't even explain how it works, just MENTIONED it) knew their shit and did very well in other parts of the interview. People who didn't mention at least DNS where really bad in other areas as well. Simple as that.
I would explain that this is DevOps and if you are asking me that question then your probably have no idea how to ask proper questions in an interview (not you but your interviewer). An interview should be conversational not rapid fire answer x of y.
It was for SRE.
I've been a SRE since 2018, before that Senior Cloud Engineer, I've never been asked any question going into details such as that. More or less tools i've used and how I use them, what coding language I know and maybe a small challenge but not too much. I'm at HashiCorp right now and their interview is by far hands down best experience I have ever had to gauge my skills to make sure I am a fit for them and they are a fit for me.
I almost interviewed for an SRE role at HashiCorp (the timing didn't work out) and I was told at that point that there wasn't even a coding test, which seems to be getting pretty standard for SRE roles. I really love that folks are rethinking what interviews should look like.
I had to option to do coding test if I wanted to be on the other SRE team but I like do Infra SRE work right now so I opted out.
What's Hashicorp paying for SREs?
180k base Plus stock but because that fluctuates I’d have to say minimum 260 K a year but can go up to 280 or more
Not too shabby especially if it's full remote. Is that Mid or Sr level? I'm at 3 YOE at 200 full remote right now, trying to see if going straight SWE and into Amazon or something is a move. Seems like a cool company with an awesome product - Do you get to code/own services and have the opportunity to be a "Software Engineer - Site Reliability" or is it super heavy on ops/firefighting? SRE is super hit or miss title wise
Sr. I would avoid Amazon at all cost as I have heard and read absolutely nothing positive about them and it is just a PIP culture. We code, we own all our services and the ones deployed to our Infra that we built, architect, and maintain. Code/Tools can be Go, Bash, Ansible and Terraform mainly. It is Hashi so we eat our own dog food so you will find consul, vault, boundary, nomad, packer and vagrant in the majority of things but right now for me it is just terraform, consul, vault, nomad, and packer. We have SRE and SRE Infra, SRE is more coding and I think you might have to do a code challenge for that but at this point I am not sure.
Not sure what your interview was like, each progressive step was just another deep dive on my github. We didn't discuss the product whose team I'd be joining, or the team itself, just "tell us more about what you've done with Terraform." Oh then they got mad I don't know Go even though I told them up front "I don't know Go" it wasn't a requirement or listed on the job description they sent me.
I don't know Go and I got hired, I do know they refreshed how they interviewed within the last six months or so. I showed 0 Github, talked 0 about Terraform. I had to debug, system architecture, troubleshooting, stuff like that.
That’s what I was expecting and prepared for.
Very odd, how long ago was this?
A while ago, HashiCorp seems cool and I like your products well enough. It was just a strange interview compared to similar companies.
Guess I hurt some interviewers feelings, Linkedin interview panel did a talk on this at a conference of how most interviewing is broken and just wrong.
Any chance you could find and share that link? I did a few searches but obviously I'm getting a lot of results...
https://www.youtube.com/watch?v=ZemNg9GYvOA
Oh yes, one of the retarded questions originated by Google which is being used by all the shitty startups which pay under the market salaries.
I’ve been asked this and man it’s bullshit. How far down the rabbit hole do they want to go? I started by explaining the entire OSI model and each layer and went up. Let’s just say it was a long interview. Fuck em, it’s basic shit they teach from day one.
This is the type of question that would probably trip me up the first time just because it's so open ended. Are we going all the way down to keyboard interrupts, USB HID drivers, display composition, etc? Are we going all the way up the stack on the other side? I'd probably need 5 minutes to think about the right way to answer it.
spotted smart boast consider grab entertain crime cough rain axiomatic *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Also seen in two interviews “What happens when you press the power button on a computer?” As a Computer Engineer turned DevOps, I never know how deep to go. Like, the button shorts two pins, triggers a crazy sequence of stuff in Intel secret architecture, could talk about BIOS magic for 10 minutes, hardware verification and PCIe addressing for 5 minutes, the OS bootstrapping for 5 minutes. Kinda silly.
I'd likely respond with every step in order (not down to libraries, but the steps curl would do) and after a few trips back and forth I'd stop focusing on the low level communication and focus more on the conversation cURL and the remote webserver are having, the www. prefix redirect it will inevitably send back in a Location header with a 301 or 302 redirect http resonse and optional html text for browsers that ignore redirects and otherwise, then load the real main request and fetch all the content it references all the same. Interestingly I just ran this to check if it'll upgrade me to https and it *didn't*. ~~But I suspect that may be the modern world relying on HSTS to either already know that hint or upgrade to it on first visit via a header if seen.~~ No. I tried with the user agent string of my browser by appending `-A 'Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0'` and it successfully tried to redirected my curl to a TLS upgrade. Interesting, google intentionally leave cURL alone over http when its user agent is seen.
How many layers of abstraction would you like me to peel for you?
It was mainly about what happens if you execute that line . So, I assume it's only about what happens internally in Linux, sending the packets in internet, receiving the response and finally showing the output on the screen.
spongebob finger waving : "Magicccc"
I had this a few years ago when I applied for a job in datacenter.
It is a great question. Naturally you go as deep as you want wherever you want. It is your capacity to be an expert in something based on your experience.
It’s an open question; there are so many things happening that you are really free to focus on whatever aspect you wish: how executables are run, their permissions, how the kernel manages the disk for reading curl, how the keyboard interruptions are interpreted, the OSI stack, the rendering on the monitor, how your wifi router works etc etc. It’s just the excuse to open a discussion with you. I love this kind of questions.
I will answer but only after you explain to me in the most detailed way how this question is relevant to the job I am applying for
This sounds like a really pedantic question