Chapter 14: Common Networking Interview Questions

Why this matters

A handful of questions — "explain the TCP three-way handshake," "what's the difference between TCP and UDP," "walk through a DNS lookup" — recur across networking interviews with enough frequency to deserve dedicated, fully-worked model answers, following the same layered structure the companion Operating System book used for its own recurring interview questions. This chapter consolidates them, and closes with the same reusable meta-skill for structuring any networking explanation under pressure.

Model answer 1: "Explain the TCP three-way handshake and why it's necessary."

Layer 1 — the problem: "TCP needs both sides to agree they're ready to communicate reliably before any actual data is sent — without this, either side might send data the other isn't prepared to receive or acknowledge correctly."

Layer 2 — the mechanism: "The client sends a SYN with an initial sequence number. The server responds with a SYN-ACK, acknowledging the client's sequence number and providing its own. The client sends a final ACK, acknowledging the server's sequence number. At this point both sides have confirmed they can send and receive, and have agreed on starting sequence numbers for tracking data order — the connection is established."

Layer 3 — the cost and mitigation: "This costs at least one full round trip before any application data can be sent — a real, measurable latency cost, especially on high-latency connections. This is exactly why connection reuse (HTTP keep-alive, connection pooling) matters: it avoids paying this handshake cost on every single request."

If pushed further: "This connects directly to why TLS adds its own additional handshake on top (for HTTPS) — and why QUIC/HTTP/3 specifically combines the transport and TLS handshakes into one, reducing this compounding round-trip cost."

Model answer 2: "What's the difference between TCP and UDP? Give a real example of when you'd use each."

Layer 1 — the problem: "Applications have different tolerance for loss, reordering, and latency — a single transport protocol design can't be optimal for both a file download and a live voice call."

Layer 2 — the mechanism: "TCP guarantees ordered, complete, reliable delivery via acknowledgments and retransmission, at the cost of connection setup and head-of-line blocking. UDP sends discrete datagrams with no guarantees at all — no handshake, no retransmission, no ordering — but essentially no overhead beyond the data itself."

Layer 3 — the cost and mitigation: "TCP's reliability mechanism can actively hurt latency-sensitive, loss-tolerant applications — if one packet is lost, TCP holds back all subsequent, already-arrived data until the lost packet is retransmitted. For something like a live voice call, a late packet describing 20-millisecond-old audio is often worse than simply skipping it — so voice/video calling protocols run over UDP and handle loss themselves, usually by just accepting it gracefully."

Concrete example: "I'd use TCP for anything where complete, correct data matters more than raw timeliness — loading a webpage, downloading a file, an API request. I'd use UDP for real-time media (voice/video calls) or fast-paced multiplayer game state updates, where a late retransmission is less useful than simply moving on to the next, current update."

Model answer 3: "Walk through what happens during a DNS lookup."

Layer 1 — the problem: "Computers route traffic using numeric IP addresses, but humans need memorable domain names — DNS translates between the two, and it needs to scale to the entire internet without any single server knowing every domain."

Layer 2 — the mechanism: "If nothing is cached, a recursive resolver queries a root server (which points to the right top-level-domain servers), then a TLD server (which points to the domain's authoritative name server), then that authoritative server directly, which returns the actual IP address. The result is cached at every level along the way, for the duration of the record's TTL."

Layer 3 — the cost and mitigation: "Each of those is a separate network round trip, so a fully 'cold' lookup adds real latency before any actual application request can even begin — this is exactly why caching, governed by each record's TTL, matters so much for real-world performance, and why lowering a record's TTL in advance of a planned migration is a standard operational practice, so the eventual real change propagates quickly rather than being stuck behind a long-cached previous value."

If pushed further: "DNS also illustrates an interesting transport choice — it typically runs over UDP for speed on small request/response pairs, falling back to TCP specifically when a response is too large for a single UDP datagram."

The reusable meta-skill

[SENIOR INSIGHT] Every model answer above follows the same four-part shape, directly mirroring the companion OS book's own interview-answer framework — worth stating explicitly, since it generalizes to virtually any "explain X" networking question:

1. State the problem being solved before describing the mechanism.
2. Describe the mechanism concretely, with a diagram or example where useful.
3. Name the real cost or trade-off the mechanism introduces.
4. Connect it to a related concept if a natural bridge exists — this is what turns a memorized answer into a demonstration of a genuinely connected mental model, and it's exactly what invites (and lets you comfortably handle) an interviewer's "tell me more about that" follow-up.

Common mistakes

1. Reciting a memorized definition of a protocol/mechanism with no structure, leaving the interviewer to extract real understanding through follow-up questions instead of seeing it demonstrated proactively.
2. Answering "TCP vs UDP" with only "TCP is reliable, UDP is fast" — this book's Chapter 4 covers exactly why this framing, while not wrong, misses the deeper and more interview-differentiating reasoning about why a specific use case benefits from one over the other.
3. Not being able to state a concrete example use case for each concept explained. An abstract, correct definition is a good start; a specific, well-reasoned example (voice calls for UDP, webpage loading for TCP) is what demonstrates the understanding is connected to real systems, not memorized in isolation.
4. Treating every question as requiring the deepest possible answer immediately rather than the layered structure that lets an interviewer steer toward the depth they actually want.

Discussion / interview questions

(This chapter's own questions ask you to apply the meta-skill to a topic not already modeled above.)

1. "Using the problem → mechanism → cost → connection structure from this chapter, explain the TLS handshake." Strong answer: Problem (need encryption, integrity, AND authentication over an inherently insecure network — not just encryption alone), mechanism (asymmetric crypto briefly establishes a shared secret, symmetric crypto handles the actual data, a certificate chain provides authentication), cost (an additional round trip on top of TCP's own handshake), connection (why QUIC/HTTP/3 folds this into one combined handshake instead of two separate ones).

2. "Apply the same structure to explain what a CDN does." Strong answer: Problem (physical distance imposes a hard latency floor that can't be engineered away at the application layer), mechanism (caching content at geographically distributed edge servers close to users), cost/trade-off (cache invalidation complexity; only helps genuinely cacheable content), connection (partial resilience during origin outages, and why static assets often stay available when dynamic content doesn't).

3. "What makes an answer to a networking 'explain X' question feel like genuine understanding rather than a memorized definition?" Strong answer: Cites the layered problem→mechanism→cost→connection structure as the actual differentiator, and notes that offering a concrete example use case unprompted (not just waiting to be asked "when would you use this?") is a strong additional signal of real, connected understanding.

Chapter summary / cheat sheet

• TCP handshake (model answer): problem (need mutual readiness before reliable data transfer) → mechanism (SYN, SYN-ACK, ACK) → cost (round-trip latency) → connection (why connection reuse and QUIC's combined handshake both exist).
• TCP vs UDP (model answer): problem (different applications tolerate loss/latency differently) → mechanism (reliable+ordered vs. unreliable+minimal) → cost (TCP's head-of-line blocking can hurt real-time use cases) → concrete examples for each.
• DNS lookup (model answer): problem (names need translating to IPs, at internet scale) → mechanism (recursive resolver walking root → TLD → authoritative server) → cost (multiple round trips when uncached) → connection (TTL-driven caching and its operational implications).
• The generalizable structure for any networking interview explanation: problem → mechanism → cost → connection — the same reusable shape as the companion OS book's Chapter 14, now applied to this subject.

---