24 topics · interview-ready
Computer networks, one layer at a time
The internet works because nobody had to solve the whole problem. Each layer solves exactly one thing and lies to the layer above about how hard it was — and every protocol you'll be asked about is one layer coping with the mess beneath it.
How to study networks
- Work one packet, end to end, until it's boring. Typing a URL touches DNS, ARP, IP, TCP, TLS and HTTP in order. If you can narrate that whole chain without stopping, you have covered about 70% of what gets asked — and it's literally the single most common question in the subject.
- For each protocol, ask "what does it guarantee, and what does it push upstairs?" IP guarantees nothing and pushes reliability to TCP. TCP guarantees an ordered byte stream and pushes framing to the application. Knowing where a guarantee stops is the whole subject.
- Run the commands.
dig,traceroute,curl -v,ss -tn,tcpdump. Networks is the most observable subject of the four — every concept has a command that shows it happening, and interviewers in backend and SRE roles ask in exactly those terms.
Not whether you can list the seven OSI layers. They want to know if you can debug a connection: why is this request slow, why does it work over HTTP but hang over HTTPS, why can this container reach the internet but not the database, why does the first request take 300 ms and the rest 20 ms. Every topic page ends with what you'd actually see.
The 24 topics
Foundations — the bottom two layers
IP & routing — getting across the world
Transport — the layer interviews live in
Application — what you actually build on
Security — the layer nobody skips any more
The interview section has the full "what happens when you type google.com" walk-through, a 62-question bank with answers, a packet-debugging drill, and the distinctions that get tested.
The 24-day plan
One topic a day. Tick a day when you can explain it out loud and name what the layer above has to cope with. Progress is stored in this browser only.
The one big idea
Each layer adds a header, hands the result down, and trusts nothing. Read this diagram once properly and half the subject's questions become mechanical.
Numbers worth memorising
The mistakes that cost marks
- "TCP guarantees delivery." It guarantees either delivery in order or an error. It cannot make a cut cable work.
- "UDP is unreliable so it's worse." It's a different contract, chosen deliberately by DNS, video and QUIC.
- "A switch and a router are basically the same." Different layers, different addresses, different failure domains.
- "HTTPS encrypts everything." The SNI hostname and the IP are visible; traffic size and timing leak too.
- "HTTP/2 fixed head-of-line blocking." It fixed it at the HTTP layer. TCP's remains — which is exactly why QUIC exists.
- Confusing bandwidth with latency — adding bandwidth doesn't fix an RTT-bound transfer.
- Confusing flow control (protect the receiver) with congestion control (protect the network).
- Saying "IP address" when the answer needs "MAC address" — or forgetting the MAC changes each hop.
- Describing a firewall as if it were a NAT, or a VPN as if it were anonymity.
- Treating DNS as instant. It's a full round trip, sometimes several.
"UDP has no handshake, no ordering and no retransmission, so a DNS query is one packet out and one back rather than three packets before you've asked anything. The cost is that if the reply is lost, the application has to notice and retry — which resolvers do. That trade is only worth it because the query is small and idempotent; for a 5 MB file you'd want TCP doing that work for you."