
What happens when you load a URL? (2015) - caiobegotti
https://danluu.com/navigate-url/
======
yarone
Reminds me of "I, pencil":

"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...](https://oll.libertyfund.org/titles/read-i-pencil-my-family-tree-
as-told-to-leonard-e-read-dec-1958/simple)

------
colinrand
I ask this question from time to time and look for different responses
depending on the type of candidate. When I ask an engineer, I am looking to
see if they can grasp the problem space and ask clarifying questions about
what I'm looking for. When I'm interviewing for an engineering manager I am
looking to see if they can grasp the problem space and ask clarifying
questions about what I'm looking for. Since I tend to work on technical
products, when I interview a product manager I tend to look for...

So much of the engineering mindset jumps to solutions instead of clarifying
problems. I'm guilty of this constantly.

~~~
mjw1007
The trouble with doing this in an artificial situation like an interview is
that you're leaving the candidate to guess your purpose.

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

~~~
Karunamon
Believe it or not, the last couple interviews I did, I just came out and asked
for, and got, this level of clarification as to what they wanted here. Some
companies solve their problems differently, value different characteristics,
and so run their interviews differently, and in my (admittedly limited)
experience, it's not a faux pas to ask.

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.

~~~
fractionalhare
I might be nitpicking, but this:

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

~~~
Karunamon
_In my interviews, I lay out two explicit expectations for the candidate
upfront.._

See, I've never once gotten that without asking for the detail. I'm convinced
that most companies have pathologically bad interview practices.

~~~
jrott
Most companies do have pathologically bad interview practices. The usual thing
it to cargo cult off of other companies interview practices or be based off of
some idea that has been seen before.

------
AndrewStephens
I tried writing an answer to (almost) this exact question in non-technical
language[0], starting from packets and working upwards.

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...](https://sheep.horse/2017/10/how_you_are_reading_this_page.html)

------
aronpye
Reminds me of when Richard Feynman analysed the question of “how do magnets
work?”. There are so many levels to it, coupled with assumed knowledge, that
the question itself is shown to be improperly bounded.

~~~
nitrix
A fascinating man and video. Link for the interested:
[https://www.youtube.com/watch?v=36GT2zI8lVA](https://www.youtube.com/watch?v=36GT2zI8lVA)

~~~
serniebanders
I don't find the video fascinating, quite the opposite actually. Richard
Feynman could have just explained the electrical force and left out the rest.
When someone asks, `why does x work`, its a sign that they are curious and
ready to explore and learn. Its an opportunity to teach and educate.

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.

~~~
aronpye
I think in this example Feynman was using the question to illustrate the
levels of complexity in answering a scientific question. If you watch his
actual lectures, Feynman does break the concepts down in order to teach them.

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.

------
nickelpro
I find I run into similar discussions whenever a beginner programmer decides
they want to capture input from the arrow keys.

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.

~~~
qertistick
You use a game library for this and then it becomes as simple as pushing a key
handler onto the event loop and usually the keycodes are already processed for
you as well. I don't get the false dilemma people are creating that somehow
this is complicated or that people who use the easy way are less knowledgable
than others. If you make a game engine from scratch by yourself it's going to
be a logical disaster, whether you've learned c++ or python.

~~~
MaxBarraclough
> You use a game library for this

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?

------
bookmarkable
Interesting, but couldn't you ask this of any existing technology with years
of development and realize you don't know how we arrived at a function we take
for granted?

What happens when you press the accelerator on your car?

~~~
squeaky-clean
This would be my perfect coffee table book. "What Happens When I X", or
something.

~~~
foota
You may like Randal Munroe's (of xkcd) books if that sounds intriguing.

~~~
squeaky-clean
"Thing Explainer" and "What If" are my current coffee table books actually,
hahaha, so spot on with the recommendation. I want a second copy of Thing
Explainer because my friends have flipped through it so much.

------
klodolph
I was given this as an interview question once, it was fun. I was told to go
into “as much breadth and depth as possible” but I did get stopped a couple
times when I started talking about things like debouncing.

~~~
borgchick
I've asked this question a number of times in interviews. Sadly, not one
person has ever talked about debouncing. I think I would've instantly hired
the person, if they talked about debouncing :P

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.

~~~
kamyarg
can you link to a resource for reading about debouncing?

~~~
kens
The Art of Electronics has a good section on debouncing switches. There are
various analog and digital ways of doing it, from R-C smoothing to latches to
debounce ICs to microcontrollers.

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...](http://www.righto.com/2018/01/ibm-mainframe-tube-module-part-ii.html)

------
kaycebasques
Another great resource similar to _How Browsers Work_ [1] is Mariko's _Inside
look at modern browsers_ series [2]

[1]
[https://www.html5rocks.com/en/tutorials/internals/howbrowser...](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

[2] [https://developers.google.com/web/updates/2018/09/inside-
bro...](https://developers.google.com/web/updates/2018/09/inside-browser-
part1)

Disclosure: Mariko and I are on the same team; I didn't work on that series

------
1vuio0pswjnm7
Interesting that he skipped the part about parsing the URL and generating the
HTTP (httpMethod, path, headers), assuming that is the protocol. It seems
relatively simple but unless one is careful there are some gotchas. Perhaps
that is why this particular part of the process ends up in so many "web
security" write-ups; many people, including the author, just do not think it
is significant. He also asssumes that the client is a "browser".

------
qertistick
I was once curious about this sort of thing. I hate that I didn't know how a
computer worked from the ground up, it made them feel like magic when I knew
they were just clever machines. I wasn't satisfied with learning about
circuits so I went even lower and asked how transistors work. I spent a long
time in a deep rabbit hole learning chemistry so I could understand why
capacitors keep charge and etc. That's when I realise to learn every layer of
a computer to a level of expert proficiency is a lifetime's work, not
something you can expect one person to be able to do off the top of their
head.

This is why we work together, we are not swiss army knives.

------
loa_in_
I appreciate author's quest for bottom-up understanding of all the things we
depend on daily. The quote "We are standing on shoulders of giants" really
shines here, and we all do a great service to them by trying to understand.

------
zoomablemind
A nice why-and-why journey. Yet as an interviewing approach this seems to lack
an initial premise, the need.

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?"_

------
davidhyde
Your browser tries to guess if what you have typed is is a url or a search
query. If you’re using chrome then there is a chance that your request will
hit a root domain name server so that the browser can check if you are
connected to a scammy Internet service provider or some other ad serving
intermediary. [https://arstechnica.com/gadgets/2020/08/a-chrome-feature-
is-...](https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-
enormous-load-on-global-root-dns-servers/)

------
canadian_tired
Asked of Cliff Stoll for his PhD defense: "Why is the sky blue?"

------
kaycebasques
> How does the browser know to try to load a webpage? I guess it sees an
> "[http://"](http://") or just assumes that anything with no prefix is a URL?

Question #7 seems related to that Chromium DNS lookup algorithm [1] that has
been getting attention recently

[1]
[https://news.ycombinator.com/item?id=24231857](https://news.ycombinator.com/item?id=24231857)

------
kaycebasques
There seems to be a need for resources about browser internals. This is
something we could potentially pursue on web.dev. However, it's a big field.
Can you all help me by:

* 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

------
fortran77
This used to be a standard interview question I'd ask potential junior
candidates. I'd see how far down I can get them to go.

------
lxe
Another interesting thought exercise would be "can you accomplish X with as
few layers/infrastructure/historical context/complexity as possible?"

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.

------
athenot
I really like this question. What I get out of it is where the candidate
focuses on, and where they gloss over. I find it useful to prefix the question
with a statement about there being no "right" answer, and "go in as much
detail as you want or know".

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.

~~~
toast0
If you don't want to hear about USB details, beware, clicking often involves
USB mice.

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.

------
thecrumb
A bit dated as well. It's assuming I'm using a physical keyboard. Today I
might be using my phone. Might be using voice recognition. It might be my
fridge hitting a URL using IoT to order me some more beer.

------
tester756
I think it lacks of:

Parsing and js execution

TLS Handshake / algo negotation

Cache

------
mattlondon
This is why I love this question as a phone-screener for onsite interviews and
stuff.

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.

~~~
ceejayoz
> 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 checking for HTTPS certificate revocation during the
> TLS handshake etc, you know they are probably worth bringing in for a face
> to face.

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.

~~~
hideo
I wouldn't consider it bizarre if a candidate has deep knowledge about
something different than what I expected when I started. I'd consider that
pretty normal actually, since most people don't work on the same thing.

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.

~~~
ceejayoz
> 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.

