Networking Interview Checklist

Learning goals

By the end of this chapter you should be able to:

• Deliver a coherent out-loud story from browser click to HTTP response
• Hit every major hop: DNS → TCP → TLS → HTTP, plus LB, CDN, NAT where relevant
• Use this as a self-test checklist before interviews
• Know where to deep-review weak spots in this course and system design material

This is the capstone. No new protocols — only integration. Interviewers rarely ask “define SYN.” They ask: “User hits Enter on https://shop.example.com — what happens?” You should narrate in order, plain English first, then precise terms when probed.

How to use this checklist

1. Pick a scenario (browser page load, mobile API call, service-to-service gRPC).
2. Set a timer for 3–5 minutes.
3. Talk out loud — gaps you stumble on are study targets.
4. Repeat until smooth without reading notes.

Mark each section ✅ when you can explain it cold.

Scenario A — Browser loads https://shop.example.com/products

1. DNS — name to address

Plain English: Browser needs an IP for shop.example.com. It asks the system resolver, which may walk recursive DNS (root → TLD → authoritative) or read a cached answer.

Precise: check hosts file, OS cache, then resolver; A/AAAA records; TTL controls cache lifetime; CNAME chains (e.g. to CDN).

CDN twist: name may resolve to Anycast or GeoDNS edge IP, not origin.

✅ Can you explain caching and why stale DNS slows incident recovery?

2. TCP — reliable pipe

Plain English: Browser opens TCP to IP port 443. Three-way handshake (SYN, SYN-ACK, ACK). Shared Internet, packet switching — but app sees ordered bytes.

Failure modes: DROP → timeout; REJECT/RST → fast refuse; wrong private IP → unreachable.

✅ Can you separate IP routing from TCP reliability?

3. TLS — encrypt and prove identity

Plain English: On top of TCP, TLS handshake: versions/ciphers, server certificate chain, key agreement, Finished proves matching keys. Then HTTP is encrypted.

Precise: leaf + intermediate certs; SAN must match hostname; symmetric keys for bulk data; session resumption on return visits.

Not in SYN: public keys appear in TLS, not TCP handshake packets.

✅ Can you explain cert chain and why expiry breaks everything?

4. HTTP — request and response

Plain English: GET /products HTTP/1.1 with Host, Accept, cookies. Server returns status, headers (Cache-Control, Set-Cookie), body.

HTTP/2+: multiplexed streams on one connection; HTTP/3 uses QUIC over UDP (transport chapter).

✅ Can you name headers affecting caching and cookies?

5. Load balancer — if present

Plain English: DNS may point to LB, not one server. LB picks healthy backend; may terminate TLS; adds X-Forwarded-For.

L7 routes on path/host; L4 forwards connections without reading HTTP (unless TLS terminated).

✅ Can you draw client → LB → app and say where cert lives?

6. CDN — if static assets

Plain English: cdn.example.com/logo.png hits edge cache; miss pulls origin once; hit is fast.

Cache key = URL + negotiated headers; purge / fingerprint for deploys.

✅ Can you explain stale content and Cache-Control: max-age?

7. NAT and private networks — on the return path

Plain English: App servers often sit in private subnets; only LB has public face. Outbound updates via NAT gateway.

Firewalls: security groups allow 443 from LB SG only to app tier.

✅ Can you explain why you cannot SSH to 10.0.x.x from home?

8. Reliability — when something breaks

Plain English: Client uses timeouts; retries only when safe (idempotency keys for payments); circuit breaker stops hammering sick deps.

Retry amplification makes brownouts worse.

✅ Can you give a safe retry policy in one sentence?

Scenario B — Internal service call (shorter)

Private DNS / Kubernetes ClusterIP → optional mTLS → no CDN; still timeouts, idempotent retries, mesh egress. ✅ Contrast with the public path above?

One-paragraph “full stack” script (template)

Use this skeleton, customize details:

User enters URL → DNS resolves name (cached or recursive) to LB or CDN edge IP → TCP handshake to port 443 → TLS handshake validates cert chain and establishes session keys → HTTP GET encrypted inside TLS → CDN may serve from edge cache or forward to origin behind LB → LB routes to healthy app in private subnet → app may call DB over private network → response travels back with Cache-Control → browser caches per headers → connection may reuse via keep-alive / TLS resumption on next click.

Practice until this flows in under 90 seconds, then add depth where interviewer probes.

Rapid-fire definitions (30-second each)

Common mistakes in interview narration

1. Starting with HTTP before TCP/TLS — wrong order confuses listeners.
2. Saying keys exchange in SYN — instant credibility loss.
3. Ignoring DNS — “browser just knows the IP.”
4. Treating CDN as magic global disk — miss path and purge reality.
5. No failure story — add one timeout or 503 retry branch.

Practice checkpoint

1. Narrate DNS → TCP → TLS → HTTP in order for one HTTPS page load. Answer: see Scenario A sections; DNS resolves name, TCP opens port 443, TLS validates cert chain and derives keys, HTTP request/response flows encrypted.

2. Where can latency hide in that path? Answer: DNS cache miss, TLS cold start, cross-region RTT, CDN cache miss, slow DB behind LB.

3. Name three interview narration mistakes that lose credibility fast. Answer: HTTP before TCP/TLS; keys in SYN; ignoring DNS; treating CDN as instant global disk; no failure/timeout story.

4. Self-grade 0–2 on: cert chain, L4 vs L7, CDN cache key, NAT, retry amplification. Target 8+ / 10. Answer: revisit chapters where you scored 0–1.

Interview angles

• “Explain HTTPS” — always ordered stack; offer to go deeper on any layer.
• System design — tie networking to latency budgets, multi-region, caching, failure domains.
• Debugging — curl -v, openssl s_client, dig, traceroute: which layer each tool exposes.
• Tradeoffs — TLS terminate at edge vs end-to-end; retry vs fail fast.

Course complete — where to go next

You finished the Networking course path. Solid next steps:

• Deep review: /networking/learn/foundations/how-https-works/ — the full TCP → TLS → HTTP story with teaching-first prose.
• System design lens: /system-design/learn/core-concepts/networking-essentials/ — same ideas in architecture interview framing.

Keep this checklist bookmarked. Run it weekly until narration is automatic — then use interview time to show judgment (tradeoffs, failures), not just vocabulary.

Course status: complete — no next chapter.