The google.com Interview Answer Is Years Out of Date

Every engineer has rehearsed the answer: browser resolves the domain over DNS, opens a TCP connection, performs a TLS handshake, sends an HTTP GET, parses HTML, renders the page. It's the canonical response to the canonical interview question, immortalized in the what-happens-when repo that's been collecting stars since 2015.

Here's the problem: for the exact site the question names, that answer has been wrong for years. Type google.com into Chrome today and there is no TCP connection, quite possibly no cleartext DNS query, and definitely no port-80 redirect. The textbook walkthrough describes the web of 2013. The question is still excellent — but only if you treat the answer as versioned.

It starts before you press Enter

The classic story begins at Enter. Real browsers don't wait that long. Chrome's omnibox is wired into a predictor that starts resolving DNS and pre-connecting to likely destinations while you're still typing — often before you've finished the hostname. For a site you visit daily, the connection may already be warm by the time your finger hits the key. Anyone who answers "first, the browser does a DNS lookup" has already missed the first interesting thing that happens.

The second thing that doesn't happen: the http:// → https:// redirect. google.com sits on the HSTS preload list compiled into every major browser, so the browser rewrites the scheme internally and never touches port 80. That's not trivia — it's a security boundary. The classic SSL-stripping attack depended on that first cleartext hop existing.

TCP is the wrong transport

This is the biggest drift between the recited answer and reality. Chrome has spoken some flavor of QUIC to Google's servers since the mid-2010s, and the standardized version — QUIC as RFC 9000, HTTP/3 as RFC 9114 — has been on by default in every major browser for years. W3Techs counts roughly 40% of all websites advertising HTTP/3 support as of mid-2026. Actual traffic share is lower — fallbacks, proxies, and middleboxes drag it down to somewhere in the 20–35% range depending on who's measuring — but for Google, Meta, YouTube, and anything behind Cloudflare, HTTP/3 is the normal path, not the exotic one.

The handshake math explains why. TCP plus TLS 1.2 cost three round trips before the first byte of the request. TLS 1.3 cut its share to one. QUIC folds transport and crypto setup into a single round trip over UDP, and a resumed connection can send application data with zero — the request rides along with the handshake. On a 100ms-RTT mobile link, that's 300ms of dead air reduced to zero. QUIC also kills TCP's head-of-line blocking: one lost packet stalls one stream, not every multiplexed request on the connection.

So "the browser opens a TCP connection" isn't a simplification anymore. It's a description of the fallback path.

DNS isn't a cleartext UDP packet either

The recited answer treats DNS as an unencrypted UDP query to port 53, up through the resolver hierarchy. Increasingly, it's an HTTPS request. Firefox has defaulted to DNS-over-HTTPS for US users since 2020; Chrome silently upgrades to DoH whenever your configured resolver supports it. Your DNS query to resolve an encrypted connection is itself an encrypted connection — which means it needed its own DNS resolution, its own QUIC or TCP handshake, its own TLS session. The recursion is a great interview thread on its own.

DNS is also carrying more than addresses now. HTTPS resource records (RFC 9460) let a server advertise "I speak HTTP/3, connect directly" in the DNS response itself, skipping the old dance of connecting over TCP first and discovering QUIC support via an Alt-Svc header. The same records deliver the keys for Encrypted Client Hello, which closes the last major cleartext leak in the TLS handshake — the server name itself. Browser behavior here is still uneven (Safari and Firefox query HTTPS records readily; Chrome leans on them mainly for ECH), but the direction is unmistakable: the DNS layer is becoming the bootstrap channel for the entire connection.

The "server" is a building near you

The final fiction is the packet's heroic BGP journey to "Google's server." Your connection terminates at an anycast edge — a Google Front End in a metro PoP, likely single-digit milliseconds away — that handles TLS termination and speaks a private protocol to the actual backends. For most production sites the same is true with a CDN in the role: the origin your code runs on may never see the handshake at all. Time-to-first-byte is now mostly a story about edge proximity and connection reuse, not transcontinental routing.

What to actually do with this

If you run services, audit your own stack against the modern path. Two commands tell you most of it:

dig +short google.com HTTPS     # does DNS advertise h3 + ECH config?
curl -sv --http3 https://yourdomain.com -o /dev/null 2>&1 | grep -i 'alt-svc\|HTTP/'

Enabling HTTP/3 is mostly a config flip now — Caddy ships it on by default, nginx has supported it since 1.25, and every major CDN exposes a toggle. Two real trade-offs to weigh: QUIC's 0-RTT resumption is replayable, so keep non-idempotent endpoints off that path; and HSTS preloading is effectively permanent — getting off the list takes months, so don't preload a domain you might ever need on plain HTTP.

If you're interviewing — on either side of the table — the question's value was never the recitation. It's a depth probe: pick any layer and keep asking "and how does that work?" But the baseline recitation has quietly moved. A candidate who walks through the three-way handshake for google.com is accurately describing a code path Chrome abandoned as the default years ago. The strong answer in 2026 opens with "depends on the browser and what's cached — but for google.com in Chrome, there's no TCP in this story."