What happens when you type a URL into your browser and press Enter?

The PM technical interview question. Walk the DNS-to-render chain at the right depth, name the PM-relevant trade-offs, and explain it to a non-technical exec.

What happens when you type a URL into your browser?

This question surfaces in Google TPM loops, Stripe PM panels, and nearly every technical screen. The interviewer is not testing whether you can recite the OSI model. They are checking three things: can you scope your answer to the audience, do you understand where latency decisions live, and can you name the layers you actually influence. Candidates who dump a jargon chain without explaining it fail just as badly as those who stop at DNS and have nothing more to say.

Scope before you answer

Open with: “Happy to go as deep as you’d like. Do you want the full technical walk-through, or the exec-ready summary?” Most candidates skip this and launch into a monologue. Asking it signals PM communication instincts before you’ve said a technical word.

The chain, one analogy per layer

URL parsing. The browser reads the address as three parts: protocol (https://), domain, and path. Port 443 for HTTPS, port 80 for HTTP, both implied by the protocol.

DNS. The browser translates the domain to an IP by checking its cache, then the OS cache, then a recursive resolver. Cold lookup: 200-400ms. Warm: near-zero. If the domain is on the HSTS preload list, the HTTP-to-HTTPS redirect is skipped entirely.

TCP and TLS. A three-message handshake (SYN, SYN-ACK, ACK) confirms both sides can communicate before any data moves. TLS 1.3 then negotiates a secure channel in one round-trip; repeat visitors use 0-RTT resumption. In 2026, over 30% of web traffic uses HTTP/3 (QUIC), which runs over UDP and eliminates the TCP handshake overhead entirely. Chrome defaults to QUIC for eligible connections.

HTTP request and the CDN layer. The browser sends a GET with headers (cookies, content preferences, user-agent). The 2026 detail most candidates miss: the “server” is almost always a CDN edge node close to the user, not the origin. The CDN terminates TLS locally and serves from cache or fetches from origin. Cache-control headers and CDN configuration are PM decisions with direct latency impact.

Rendering. The browser parses HTML into a DOM, fetches CSS and JS, builds a render tree, calculates layout, and paints pixels. The critical rendering path is the PM-relevant concept: anything blocking the first paint delays what the user sees.

2026 addition. The Speculation Rules API (Chrome, 2024+) lets sites pre-fetch or pre-render likely next pages. By the time a user types the URL, the browser may have already fetched it: a product decision with privacy and cost implications.

Structure a strong answer

strong

"I'll start conceptually and you can pull me deeper on any layer. The URL is an address: protocol, domain, path. DNS translates the domain to an IP, starting from the browser cache and escalating only if needed. Cold lookup is 200-400ms; most repeat visits skip it. Once the IP is known, the browser opens a secure connection via TLS 1.3 (one round-trip), sends the request, and typically hits a CDN edge node rather than the origin server. The CDN returns cached content or fetches from origin. The browser then assembles the response. The PM decisions in this stack are CDN config, cache TTL (short TTL means faster incident response, longer means lower DNS cost), and HTTPS migration. Each is a trade-off between speed, cost, and reliability."

weak

"The browser does a DNS lookup, a TCP handshake, a TLS handshake, sends a GET request, gets a 200 OK, and renders the HTML." Interviewers at Google and Stripe flag candidates who name steps but cannot explain why each exists or where a PM makes a decision about it. Stopping at DNS is the other failure: it signals surface-level prep.

The exec version

Drop all acronyms: “The browser finds the server’s address, opens a secure connection, asks for the page, and assembles what you see. The interesting PM questions are about speed (what can we preload or cache) and reliability (what happens when any step fails).” Knowing when to use this version is part of the test.

Where PM judgment lives

DNS TTL is a product call: Cloudflare defaults to 5 minutes; some teams drop to 30 seconds during deploys to limit blast radius. CDN cache invalidation determines how quickly a bad release rolls back. HTTP/3 support is a configuration decision with measurable latency payoff on slower connections. In 2026, standing up HTTPS takes minutes. The question worth answering is which settings you own and what you’d trade off to change them.