Interview questions in this field have a reputation for being recall exercises, and the good ones are not. Each durable question exists because the shallow answer and the real answer are distinguishable in a sentence or two.
What follows is what each is actually testing, which is more useful than the answer.
What the standard questions probe
| Question | What it tests |
|---|---|
| What happens when you enter a URL | Breadth, and whether layers are connected |
| Difference between a switch and a router | Whether forwarding decisions are understood |
| How does ARP work | The boundary between layer two and layer three |
| Explain the TCP handshake | State, and what each message establishes |
| TCP against UDP | Whether the trade is understood or recited |
| What is a broadcast domain | Where segmentation actually happens |
| How does a default gateway work | Longest match, and what the host decides |
| Why does MTU matter | Fragmentation, discovery, and tunnelling |
The first row is the one that has survived longest, and it survives because it cannot be answered briefly and correctly at the same time. It reveals which layers a candidate is comfortable in and, more usefully, whether they can move between them.
The answers that separate people
On ARP, a weak answer describes resolving an address to a hardware address. A strong one explains that the host first decides whether the destination is local, and resolves either the destination or the gateway depending on that answer, which is the part that actually matters.
On the handshake, a weak answer names three messages. A strong one explains that each direction establishes its own sequence numbering independently, which is why the middle message carries two functions and why the connection is genuinely bidirectional rather than symmetrical by convention.
Where candidates are usually caught
Asking what happens when a switch receives a frame for an unknown destination separates people quickly, because flooding is the answer and the follow up is what stops that flood from circulating forever.
Asking why a ping succeeds while an application fails is similarly effective, since it requires reasoning about which layers each exercises rather than recalling a definition.
The questions worth asking instead
The most informative questions are diagnostic rather than definitional. Describing a symptom and asking what the candidate would check first reveals method, and method is what the role actually requires.
A close second is asking about something they got wrong. Anyone with real operational experience has an outage they caused, and the account of what they changed afterwards says more than any protocol question.
Preparing for them honestly
Memorising answers is transparent to anyone experienced, because a recited answer collapses at the first follow up question.
The durable preparation is being able to explain each mechanism at two depths, one sentence for someone who needs the outcome and several minutes for someone who needs the detail. Candidates who can move between those two comfortably are demonstrating the thing being assessed.
Note: the strongest signal in either direction is what happens after a follow up question. Genuine understanding gets more specific under pressure, while recall gets vaguer, and that difference is visible within about thirty seconds.