Computer networks interview questions — the layer where "it's slow" actually gets diagnosed
TCP vs UDP, the OSI model, DNS lookups — networking questions look academic until you're the one debugging why a service times out under load and nobody else on the team can explain what's happening at the socket level.
Networking fundamentals get asked in interviews for roles that will never touch a router, for the same reason OS questions do: they're a proxy for whether a candidate understands what's happening below the code they write every day, and that understanding shows up the moment something in production behaves strangely and "it's slow" needs an actual diagnosis instead of a shrug.
TCP vs UDP — not the definition, the tradeoff behind picking one
What gets recited: TCP is reliable and connection-oriented, UDP is faster and connectionless.
What actually gets tested: "Why would you choose UDP for something, given it can lose data?" The honest answer names a real case: video calls, live streaming, online gaming — situations where a dropped packet is better handled by skipping it and moving on than by TCP's retransmission-and-wait behavior, which would show up as stuttering or lag far worse than a momentarily glitchy frame. Naming a real tradeoff, not just the definitions, is what separates a memorized answer from an understood one.
The three-way handshake — the question that reveals whether you've actually opened a packet capture
Everyone can say "SYN, SYN-ACK, ACK." The stronger follow-up: "why three steps instead of two?" The honest answer is that both sides need to confirm they can both send and receive — a two-step handshake only proves one direction works. This is also the setup for a real production question: "what's a SYN flood, and why does it work?" A server that allocates resources for each half-open connection can be exhausted by a flood of SYN packets that never complete the handshake — which is exactly why understanding the mechanism, not just its name, matters.
DNS — the "it's not our servers" question in disguise
DNS resolution rarely gets asked as "explain DNS" directly — it shows up as "a user reports the site is unreachable, but your servers show no errors, what do you check?" A strong answer walks the resolution chain: is the domain resolving at all, is it resolving to the right IP, is there a caching issue (stale records, a low TTL that hasn't propagated, or a resolver serving an old cached answer), before ever looking at application logs. Skipping straight to "check the server" without ruling out DNS is a common tell that someone hasn't actually chased this specific class of bug before.
The OSI model — not memorizing seven layers, but locating a problem in one
The seven layers get taught as a list to memorize, and interviewers know it — which is why the useful version of this question is practical: "a request times out, where could the problem be, layer by layer?" A physical cable issue is layer 1. A switch not forwarding frames correctly is layer 2. A misconfigured route is layer 3. A firewall blocking a port is layer 4. An expired TLS certificate or a malformed HTTP response is layer 6 or 7. The value of the model isn't reciting it — it's using it to narrow down where in the stack something is actually broken instead of guessing randomly.
HTTPS and TLS — what's actually being verified, not just "it's encrypted"
"HTTPS encrypts the connection" is true and answers almost nothing. The stronger answer explains the handshake's real job: the client verifies the server's certificate against a trusted authority (so you know you're actually talking to the real server, not an attacker in the middle), then both sides negotiate a shared symmetric key for the actual encrypted traffic, because symmetric encryption is far faster than the asymmetric encryption used just to establish trust. Interviewers listening for "why not use asymmetric encryption for everything" are checking whether you understand the tradeoff being made, not just that HTTPS exists.
If you want to practice explaining networking fundamentals out loud, with a real follow-up when your answer stays surface-level, try role-specific mock interviews — free to start.