What happens when you load a URL? (2015)
danluu.com
danluu.com
"A charming story which explains how something as apparently simple as a pencil is in fact the product of a very complex economic process based upon the division of labor, international trade, and comparative advantage."
https://oll.libertyfund.org/titles/read-i-pencil-my-family-t...
So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly.
If I phrased the question slightly differently, engineers would have a very different reaction.
Q: Can you write a test for me that demonstrates I can load a URL successfully?
That could drive the engineer down a different mode of thought.
Business stakeholders won't ask for a requirement to implement a test, and the engineer needs to translate the business request into an engineering solution.
From what I've seen, different levels of experience in engineer will have different responses and illustrate for me where they are in the engineering journey. A young engineer, perhaps a new college grad or intern, will tend to react to this with a very open mind and lean on their recent academic background, showing excitement with the question and identifying the challenges in it. They usually do pretty well.
The mid career programmer often stumbles. They want to show the expertise so latch on to the part of the problem they are most familiar with do show technical prowess. They can often lose the forest for the trees.
The senior engineer, will want to know why you're asking and what you're trying to accomplish. Perhaps I'm looking to optimize one part of the problem, perhaps make a step more resilient, more extensible, etc. They will want to know why this question is important for the problems at hand, and hopefully they'll ask about that directly!
Hope this gives some insight for you.
If they correctly guess that what you mean is "please engage in a simulation of a planning conversation, based on this arbitrary prompt", they'll do well.
But if they guess that you mean "please use this arbitrary prompt as an opportunity to demonstrate the depth of your technical knowledge", they'll do poorly (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge).
A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. They wanted to be sure that you were sure when you put an idea out there without qualification, and so it was with the day-to-day SRE-ish work where short outages caused by speculative changes that weren't fully understood were wildly expensive events.
At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question, or was asked why I answered what I did if the answer was wrong; they were more interested in my thought process than the end result, even if the end result wasn't technically correct.
> A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire.
and this:
> At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question
aren't incongruous to me. In my interviews, I lay out two explicit expectations for the candidate upfront:
1. Please don't bullshit an answer. Confidently incorrect is considered a red flag.
2. The interview is designed to find the ceiling on your certainty and knowledge, and to see how you deal with ambiguity thereafter.
I encourage candidates to guess; I just want them to make it very explicit when they're guessing, and demonstrate self-awareness in doing so.
As ever, a lot of interview problems on both sides of the table are resolved with more communication. It is good to set explicit expectations for candidates throughout the process, and to revisit particular expectations in the first two to three minutes of an interview.
See, I've never once gotten that without asking for the detail. I'm convinced that most companies have pathologically bad interview practices.
Unfortunately BSing works pretty well for a lot of people. It may not work with you, but it will probably work with some other employer.
This feels backwards to me. If you have comprehensive knowledge, you almost have to narrow down the question!
Or just talk continually until you've exhausted every single detail of every single aspect. The latter is rarely going to be what you want to do.
There's a level of "this is also a test of your communications skills" in every interview question, and it's a valuable thing to look for. So if you don't treat it as a 2-way street... you probably should.
I've been listening to people expound their theories of interviewing for decades now, and very often they have some pet idea which involves asking the candidate for something and then trying to deduce information indirectly from how they interpret the request.
I think these theories are pretty much all bad ideas, because what the candidate is actually doing is trying to guess what the interviewer wants to hear.
Turns out this was the core problem for me.
I actually care about customer acquisition and marketing strategies. Product positioning is important to me and it deeply effects how the product is designed. The aspects are a conversation, not a dictation and battle between departments.
Business and marketing is how you wrap and present your technical achievements to communicate their value to the public. If this isn't part of the gestalt, then we're just a scattered swarm. Anyway, yeah, passion.
A company that thinks there should be 10 people and 500 miles between these things and who actually builds the thing isn't right for me. (Apple for instance)
This is how companies come out with spastic messes that only sell because of the existing momentum of the brand.
I would be eternally frustrated that not only me, but everyone else is in these stovepipes.
So that flaw, I realized IS the purpose. They aren't testing knowledge as much as boundaries.
It's Designed so they don't accidentally hire otherwise technically competent people who want to bombthrow their administrative apparatuses
This is because it's easier to rely on knowledge, but it takes extra work to develop understanding.
It's also a culture issue. A close friend of mine works for a web dev agency. Numerous times she's told me how they're discouraged from asking questions. They're told they are experts and experts have _all_ the answers.
Nearly as often I hear stories about something going sideways because knowledge isn't enough, they're short on the necessary understanding.
Despite the pattern, the leadership doesn't change the culture.
The document ended up much longer than I intended and I am still not sure my answer is that helpful.
[0] https://sheep.horse/2017/10/how_you_are_reading_this_page.ht...
The whole video (to his credit, Richard did explain the concept well) focuses on how little the questioner know. It is a little belittling. If someone talked like that to me I'd have gone home and accepted the fact that I just would never understand electromagnetism and moved on.
A better approach instead of actually capitalizing on this curiosity and teaching the questioner, giving them just a bit more than the normally accepted answer so the curiosity lives on.
Also, documentaries and popular science books tend to dumb down and over simplify theories to such an extent, such as by removing all mathematics, that they just become either wrong, inaccurate, or misleading. I think it was Einstein which said make things as simple as possible, but not simpler.
They've worked through the bog standard Python tutorials using input() to capture from stdin, so it should be trivial to design a simple game that uses the arrow keys right? And suddenly this gulf of complexity opens up of event polling, keycodes, integrating third party modules, and they're left wondering why moving one key over on the keyboard is so hard.
You're saying this like most beginners even have an idea what a tty is.
An anecdote: When I wrote my first C++ program that reads an input (using `cin`, hello-world style), I immediately wondered how to read single keys including arrow keys. The book I was following had nothing about this. I don't remember the exact details but a bit of Internet search got me to `conio.h` (I was using Dev-C++ on Windows) which did work. But getting it to work was so confusing to me at the time. And I didn't even get to understand what it's actually doing under the hood.
I imagine it would be a bit easier in Python given the right libraries, but the dependency management probably adds to the complexity for a beginner.
What’s the keystroke for right-arrow, spacebar, left-shift, and W all being held down?
(Think of an Asteroids arcade game where w is thrust, spacebar is fire, left-shift is shields, and right arrow is rotate. Those are up/down, not strokes, that the player is giving you.)
If it's a command-line application, they might use curses.
edit Apparently curses isn't available by default in Python3 for Windows. Is there a nice way to do this?
What happens when you press the accelerator on your car?
No single automotive engineer can answer that question to the level of detail that the original post wants to approach. A car is a collection of separately engineered mechanical devices meeting some power/torque/thermal requirements, electronic units which, to a mechanical engineer are essentially black boxes with inputs and outputs. Abstraction is in every field of engineering and it helps people reason about a complex system in terms of abstract interconnected parts, not in terms of bits, bytes, cogs or bearings.
In a similar vein, a web developer, a browser developer, a kernel developer, a network driver developer each use different levels of abstraction and paradigms in order to achieve their thing.
I guess a similar statement holds if you want to understand anything starting from nothing.
To clarify, I would ask this question as a wrap up, a sort of final probe of depth test. If they don't go into much detail, no big deal. If they were good in the rest of the interview, they'd still get hired. If they were good elsewhere but also went into depth on this question, then it really boosts their likeliness of getting hired. I find that people who are curious about how things work, especially when it is outside of their main domain, are usually people interesting to work with.
If you want a thoroughly obsolete look at debouncing, I got a debouncing module from an IBM 705 computer (1954). This module was built from 8 vacuum tubes and a pile of resistors and other components. I powered it up with an inconvenient set of voltages (+140V, -60V, -130V) and actually got it to work: http://www.righto.com/2018/01/ibm-mainframe-tube-module-part...
[1] https://www.html5rocks.com/en/tutorials/internals/howbrowser...
[2] https://developers.google.com/web/updates/2018/09/inside-bro...
Disclosure: Mariko and I are on the same team; I didn't work on that series
This is why we work together, we are not swiss army knives.
For example.
* I want to know what does a URL represent. Is it a porn site? Am I gonna be hacked/tracked?
* I need to check if this domain name is not/taken.
* I want to know if URL can contain spaces, or emojis.
* I want to know if I get a reasonably fast response.
* My phone tells me the site access is Forbidden.
Basically, a reasonable answer needs to be also a "Why?". This sets up a logical context for drilling down with an intention to locate something, not just for the drilling down sake.
"Computer, what happens...?"
"Why do you need to load a URL, Dave?"
Question #7 seems related to that Chromium DNS lookup algorithm [1] that has been getting attention recently
* Providing examples of existing resources that explain browser internals which has made you a better developer
* Listing situations in which you needed to go deeper into how browser internals work and didn't find good resources
Knowing what you need to accomplish, can you design a system from the ground up that sheds some of the traditionally expected layers and idioms and see what you can come up with.
Since I'm not hiring for hardware, when they get into minute details about keyboard and USB, I smile and gently interrupt to move to the browser making the request. Come to think of it, I may rephrase the question to "What happens when you click on a link?" since that covers browser events, CORS and all that fun; and does away with the keyboard.
More importantly, telling someone there is no right answer, and go into as much detail as they want, and then cutting them off when they do is a bad interview experience. At least guide them on where you want to focus. Or let them take you on an adventure through USB. The point of this as an interview question is to demonstrate broad knowledge as well as some detailed knowledge --- it doesn't particularly matter which knowledge.
If someone can figure out USB, they can figure out TCP, etc. You're looking for people who can figure things out. It's all distributed state management.
Maybe a little different if you're hiring a contractor than a staff member.
Parsing and js execution
TLS Handshake / algo negotation
Cache
Sounds so easy, but there is so much depth in so many areas that people can drill into. If someone starts talking convincingly about the OS handling keyboard interrupts or about HTTPS certificate revocation during the TLS handshake explanation etc, you know they are probably worth bringing in for a face to face.
Someone bluffing will usually fail this really hard - "The browser connects to example.com and downloads the page." or something. Uh-huh. Maybe they talk about DNS ... Maybe they talk about a TCP connection ... Maybe they talk about retrieving the HTML and parsing it ... but even then, if they get that far that will be better than a lot of bluffers. If they have simply revised anticipating this question and can answer everything then congrats - they've just educated themselves in a lot of the core fundamentals :)
As an interviewer this question can easily take up a whole 30 min phone screener as good candidates get deeper and deeper.
If I ask you "what happens when you load a URL" and you start talking about the operating system's handling of keyboard events, I might get the impression you're hopelessly prone to bizarre and useless digressions.
If someone goes wildly off-track and starts talking about the design of the mechanical switches in the keyboard or I am specifically interested in one area vs another then you can easily tailor it "Ok cool - lets skip ahead to the network aspects" or "lets say I've found the server and downloaded the HTML - now what?" etc.
That said, I often like to let people just talk in interviews unless I am really specifically trying to drill into one area and get specific evidence of specific skills. I might jump in with a "Ah - interesting. Tell me more about DNS" or whatever, but usually I find that the good candidates will have a lot to say, and the less-good candidates either say hardly anything, bullshit, or talk a lot but are not good communicators (confusing explanations/hand-waving/etc) ... or a combination of those things :)
I wouldn't consider it useless either, unless I'm hiring an engineer for a narrow focus on something (e.g. I want someone that knows BGP), but I've never done that.
I've found that the ability to learn is fungible.
The ability answer a question effectively instead of exhaustively is important too, though, right?
Personally, I'd be more impressed by the candidate who answers this by first asking "is there a particular aspect or perspective of this task you're most interested in?", especially if they can highlight the broad aspects involved, and offer to drill down on any in particular.
1-Is a genius and has no problem getting a job, therefore doesn't have to jump through these hoops
2- Or is probably on the autism spectrum and might be hard to work with
Same here and I'm confused as to why this comment has been downvoted. It's a perfectly good question for level setting. You get an idea of how much the person knows about various aspects of the system without having to ask pointed questions that they may not know. Instead, they get to show you what they are knowledgeable about.