Skip to content
../writing

How the Hell Did I Fumble This Interview Question!

Naseebullah Ahmadi  Senior Software Engineer, London

"What happens between typing a URL and seeing the page?" I've shipped web apps for years and still botched it. Not because I didn't know the pieces, but because I didn't have the map. Here's the answer I should have given: eight stops, in order, and where to go deep when the interviewer pulls a thread.

#interviews
#networking
#browsers
#career
4 min read
#engineering
In one line

Give the map before the detail. URL parsing and caches, DNS, TCP, TLS, the HTTP request, the server, the response, then rendering. Say all eight in one breath, then let the interviewer pick which one to dig into. Knowing every step isn't the test; telling it in order under pressure is.

"So, walk me through what happens when you type a URL into the browser and hit enter."

I'd spent the week before preparing for the hard stuff: distributed systems, consistency trade-offs, designing for a million requests a second. I was braced for complexity. Then I got the most basic question in web engineering, and my mind went completely blank.

I've built web apps for years. I've debugged DNS, fought CORS, chased render-blocking scripts. I know every piece of this. But I'd never said it out loud as one story, and I hadn't expected to need to, so nothing came.

So here it is, the version I wish I'd given.

The map first

Open with the whole route in one sentence, before any detail:

The browser figures out what I typed, checks its caches, resolves the domain to an IP with DNS, opens a TCP connection, secures it with TLS, sends an HTTP request, the server builds a response, and the browser parses and renders it.

That one sentence does two jobs. It proves you know the shape, and it hands the interviewer a menu. Most of them will stop you and say "tell me more about X." That's the point: you want them choosing the depth, not you guessing it.

The eight stops

  1. 1

    Parse the input. Is it a URL or a search? The browser fills in a scheme if you left it off and checks the HSTS list, which can upgrade http to https before any request leaves the machine.

  2. 2

    Check the caches. A service worker can answer the request outright. Otherwise the HTTP cache might hold a fresh copy and the network never gets touched.

  3. 3

    Resolve DNS. Browser cache, then OS cache, then the configured resolver. On a miss the resolver walks root, then the TLD (.com), then the domain's authoritative nameserver, and caches the answer for its TTL.

  4. 4

    Open a connection. A TCP three-way handshake: SYN, SYN-ACK, ACK. One round trip before anything useful moves. (On HTTP/3 this is QUIC over UDP instead, with the transport and TLS handshakes combined.)

  5. 5

    Secure it with TLS. Client and server agree on a cipher and exchange keys, and the browser checks the certificate chain against its trusted roots. TLS 1.3 does this in one round trip.

  6. 6

    Send the HTTP request. GET /path with headers: Host, cookies, Accept-Encoding, cache validators like If-None-Match.

  7. 7

    The server does its thing. Often a CDN edge answers first. On a miss it goes through a load balancer to an app server, which may hit a database or cache, and sends back a status, headers and a (usually compressed) body. A 301 or 302 sends you back to stop one with a new URL.

  8. 8

    Render. Parse HTML into the DOM and CSS into the CSSOM, run scripts, combine them into the render tree, then layout, paint and composite. Images, fonts and scripts the HTML references kick off their own trips through steps two to seven, in parallel.

  1. Browser to DNS: example.com?
  2. DNS to Browser: 93.184.215.14
  3. Browser to Server: TCP SYN
  4. Server to Browser: SYN-ACK
  5. Browser to Server: ACK + TLS ClientHello
  6. Server to Browser: ServerHello + certificate
  7. Browser to Server: GET /
  8. Server to Browser: 200 OK + HTML
A cold first visit over HTTPS: three round trips before the first byte of HTML.

Where they'll pull the thread

Once the map is out, expect a follow-up. The common ones, and the one thing worth saying for each:

  • "Why is the first visit slow?" Round trips. DNS, TCP and TLS each cost at least one before the first byte of HTML. That's why CDNs put servers close to users, and why preconnect and connection reuse matter.
  • "What makes rendering slow?" Render-blocking resources. CSS in the <head> blocks paint; a plain <script> blocks parsing. defer and async exist for exactly this.
  • "How does caching fit in?" At every layer: browser, service worker, DNS, CDN, app cache, database. A good answer names where each one sits in the eight stops.
  • "What changes with HTTP/2 or HTTP/3?" HTTP/2 multiplexes many requests over one connection. HTTP/3 moves to QUIC so one lost packet doesn't stall every stream.

What I'd tell past me

Don't skip the fundamentals because they feel too easy to need preparing. "Easy" questions are exactly the ones you never rehearse, which makes them the ones most likely to catch you cold.

The interviewer wasn't checking if I knew what a SYN packet is. They were checking if I could hold a big system in my head and explain it to someone in order. That's the actual job, every time you're in a design review or onboarding someone new.

So practise the one-sentence version until it's boring. Then the detail has somewhere to hang.