TL;DR: Resolution, connection, encryption, request, response, render. The depth is the point: name the resolver order and caches, the handshake and what TLS 1.3 changed, connection reuse, and the fact that the whole thing usually happens against a CDN edge rather than your origin.
How to approach it
Announce the layers you will cover, then go through them, and go deeper on whichever one this company cares about. You are being measured on how far you can keep going, so do not summarise.
A strong answer
Resolution. The browser may use its own cache and DNS-over-HTTPS resolver, bypassing the OS resolver. When using the Linux system resolver, NSS configuration reads /etc/nsswitch.conf to decide order and /etc/resolv.conf for nameservers and the search list. If it is a relative name, the search domains are tried first, governed by ndots. A cache miss goes to the configured recursive resolver, which walks root, then TLD, then the authoritative nameserver, honouring TTLs at each step. Worth naming: ordinary DNS commonly uses UDP with an EDNS-advertised payload limit and retries over TCP when truncated; 512 bytes is the legacy limit without EDNS, and DNS is usually the first place latency hides.
Connection. With an address, a TCP connection: SYN, SYN-ACK, ACK, one round trip before any data. The kernel picks an ephemeral source port, the connection enters the accept queue on the server, and the application accepts it. If the server is behind anycast, the packet lands at whichever edge the routing table considered nearest, so the same anycast IP can route different users to different sites without a different DNS answer.
Encryption. TLS handshake on top. In TLS 1.2 that was two more round trips; 1.3 cut the normal handshake to one round trip. Resumption can optionally send replayable 0-RTT early data when both peers permit it, which is why it materially changed page load time. The client offers cipher suites and SNI (in cleartext, which is why ESNI and ECH exist), the server presents a certificate, the client validates the chain to a trusted root and checks expiry, hostname and revocation. Certificate expiry is the single most common self-inflicted outage in this whole chain.
Request. An HTTP request goes over the established connection. Over HTTP/2 or HTTP/3 it is multiplexed with others on one connection, which is exactly why layer 4 load balancing distributes it badly. HTTP/3 replaces TCP with QUIC over UDP and folds the transport and TLS handshakes together.
Response. Almost certainly served by a CDN edge. If cached and fresh, it never reaches your infrastructure. If not, the edge fetches from origin, where a load balancer picks a backend, which may hit a cache and then a database. Cache-control and ETag decide what happens next time.
Render. The browser parses HTML, discovers subresources, and fetches them, which repeats this entire process per origin. That is why domain sharding used to help and now hurts under HTTP/2.
What interviewers probe next
"Where would you look if it were slow?" Split it: resolution time, connect time, TLS time, time to first byte, and content download. curl -w gives all five, and the slow one names the layer.
"What does TCP_NODELAY do?" Disables Nagle's algorithm, which batches small writes. For a chatty request-response protocol Nagle interacting with delayed ACK produces a characteristic 40ms stall.
"Why does the same URL resolve differently for different users?" GeoDNS or CDN answer selection can return different addresses. Anycast instead lets one address route to different sites.
Common mistakes
Rushing to "and the server responds". The interviewer wants the depth, and stopping early is the answer they are scoring.
Skipping the CDN. In production most requests never reach the origin at all.
Not knowing what is in /etc/resolv.conf, which is the fastest way to reveal that the Linux half is theoretical.
References