What Happens When You Type google.com? How It's Really Scored

I have asked "what happens when you type google.com into your browser and press enter?" more times than I can count. The best answer I ever heard took four minutes. The worst took twenty-two, and the twenty-two-minute guy knew more networking than the four-minute one did.

He knew ARP. He knew the TCP congestion window. He knew the difference between a recursive and an iterative DNS query. He talked for twenty-two minutes and I still had no idea whether he could find out why a page was slow.

That is the whole trick of this question. It has no bottom, so it never tests knowledge. It tests how you behave when there is no bottom.

TL;DR

• "What happens when you type google.com" is a depth probe, not a quiz. There is no correct stopping point, so the interviewer is measuring how you navigate an unbounded problem.
• Score comes from breadth first, depth on demand: cover the whole chain in 3 to 5 minutes, then go deep only where the interviewer pushes.
• Saying "I know this layer roughly, I have never implemented it" scores higher than bluffing. Interviewers are calibrating how much they can trust your confident statements later.
• Senior engineers fail it by monologuing into their favorite layer (usually TCP) and never reaching the render path.
• The follow-ups decide the round, not the recital: "where is that cached?", "the page is slow, where do you look first?"

What is the "what happens when you type google.com" interview question actually testing?

It tests whether you have one connected mental model of the stack, or a pile of disconnected facts. Everything between a keystroke and a painted pixel is in scope: input handling, DNS, transport, TLS, HTTP, server topology, browser rendering. Nobody knows all of it. That is the point.

An interviewer learns three things in the first two minutes:

1. Do you have a map? Can you name the layers in order without wandering?
2. Where is the edge of your map? And do you say so out loud, or do you fog it up with vocabulary?
3. Can you be steered? When I say "go deeper on TLS", do you go deeper, or repeat what you already said louder?

Number three is the one that gets people. This question is secretly a collaboration test dressed up as a trivia question.

What is the actual chain of events?

Here is the version I want to hear. Roughly four minutes, breadth first, no layer skipped.

Before anything leaves the machine. The browser figures out whether what you typed is a URL or a search query. google.com parses as a host, so it becomes a navigation. Then the HSTS preload list kicks in: google.com ships inside the browser binary as HTTPS-only, so the http scheme is upgraded to https before a single packet exists. That detail alone separates people who have read about the browser from people who have only read about networks.

Finding the address. Browser DNS cache, then OS cache, then the hosts file, then the configured resolver. On a miss, the resolver walks root servers, then the TLD nameservers for .com, then Google's authoritative nameservers. What comes back is an anycast IP, so the "server" you connect to is whichever edge location the routing tables think is closest to you.

Opening the pipe. TCP three-way handshake, or more likely QUIC over UDP, since Chrome talks HTTP/3 to Google when it can. Then TLS: client hello with SNI so the edge knows which certificate to present, server hello, certificate chain validated up to a root in your trust store, keys agreed. TLS 1.3 does this in one round trip, or zero on resumption.

Worth saying out loud: the certificate proves the server controls the private key for that name. It proves nothing about whether the server is honest.

The request. GET / HTTP/2 with headers and cookies, into a front-end load balancer that terminates TLS and routes to backends. The response comes back, possibly a redirect to www.google.com first, with cache-control and compression headers.

Turning bytes into pixels. The HTML parser builds the DOM incrementally. CSS builds the CSSOM. Blocking scripts stop parsing, which is why script placement matters. DOM plus CSSOM makes a render tree, then layout computes geometry, then paint, then compositing on the GPU. Subresources fetch in parallel over the same connection, and the whole thing repeats for each of them.

Stop there. Take a breath. Say: "That is the outline. Where do you want me to go deep?"

That sentence is worth more than the previous four minutes.

Why do senior engineers fail such an easy question?

Because seniority creates a favorite layer, and a favorite layer is a trap. The distributed-systems person spends twelve minutes on anycast and BGP. The security person litigates certificate pinning. The infra person explains L4 versus L7 load balancing while the browser never renders anything.

They are not wrong. They are just answering a question nobody asked, and burning the interviewer's time budget doing it. Every minute you spend in your comfort zone is a minute I cannot use to find out what else you know.

The other failure mode is quieter: performing certainty. A candidate said "and then TLS encrypts the DNS lookup" with total confidence. It was wrong, and it was fine that it was wrong. What was not fine was that I now had to discount every other confident statement in the interview, including the ones about their own project. Confidence you cannot calibrate is worse than an admitted gap.

The strongest candidates do the opposite and it sounds like this: "DNS I know well. TLS I know at the handshake level but I have never implemented a cipher suite. Rendering I know from the performance side, not from the parser side." Ten seconds. Now I know exactly where to aim, and I believe you for the rest of the hour.

What follow-ups decide the round?

The recital is the setup. The follow-ups are the actual interview, and they are almost always these four:

• "You said the DNS response is cached. Cached where, and for how long?" Tests whether "cache" is a word or a model. Good answer names multiple layers and mentions TTL.
• "Why does typing google.com end up at www.google.com?" Tests whether you noticed the redirect at all, and whether you can explain apex versus subdomain.
• "The page takes eight seconds. Where do you look first?" This is the real question. It converts trivia into debugging. Anyone who reaches for the browser network panel and starts bisecting the chain instead of guessing gets a yes from me.
• "What if the DNS record is a CNAME pointing at a CDN?" The perturbation test. Memorized answers shatter here. Understood answers just keep going.

That last one has become my favorite, because a lot of people arrive having memorized a very famous GitHub write-up of this exact question. Reciting it gets you through minute four and dies at minute six. Perturbations are how interviewers separate a stored answer from a working model.

How do you practice a question with no bottom?

Out loud, on a timer, to something that interrupts you. Reading the chain silently builds none of the skill that matters here, because the skill is verbal navigation under interruption. Set four minutes, narrate the whole path, then have someone stop you at a random layer and ask "go deeper".

If you do not have a person handy, I built a tool for exactly that gap. Preterview runs realistic voice interviews with three AI interviewer styles, scores your resume and portfolio, and hands back a written report on where you rambled and where you bluffed. Full disclosure: I built it, so weigh that accordingly. It is at https://preterview.com/en if talking to a machine at 11pm beats waking up a friend.

Either way, the drill is the same: cover the map, mark your edges, invite the follow-up.

So what is the right answer?

There is no right answer to "what happens when you type google.com into your browser and press enter", and any interviewer who tells you otherwise is grading the wrong thing. The answer that passes is a four-minute breadth-first pass through the whole chain: URL parsing and HSTS upgrade, DNS resolution through the cache hierarchy, TCP or QUIC plus the TLS handshake, the HTTP request through the load balancer, the response, and the browser's parse, layout, paint. Then you stop, name the layers you know shallowly, and ask the interviewer where to go deep. You are not being scored on how much of the stack you can recite. You are being scored on whether you can be trusted to say "I do not know that part" on a Tuesday afternoon when production is down and everyone is guessing.