Prepare for networking interviews by practicing layered connectivity troubleshooting and the real scenarios behind every fundamental concept, not just definitions.
Real questions, real answers, the kind you could actually say out loud in an interview. Click any question to expand it.
Structured, layered network troubleshooting under pressure.
I work from the inside out. Is it everyone or one person, wired or wireless. Can devices reach each other on the local network. Can they reach the gateway. Can the gateway reach the outside. Is it a DNS problem or a connectivity problem.
The value is in the order, because it localizes the fault fast. If nobody can reach the gateway, it is internal, a switch, the router, or cabling. If the gateway is fine but nothing beyond it works, it is the internet connection or the ISP. If raw IPs work but names do not, it is DNS. I confirm at each layer rather than assuming.
Rebooting the router first by reflex instead of first finding which layer actually failed.
“Devices can reach the gateway and each other, but nothing on the internet works. Where do you look?”
Whether you understand the resolution chain well enough to troubleshoot it.
When you request a name, your machine checks its cache, then asks a resolver. The resolver works down from the root to the top-level domain servers to the domain's authoritative servers until it gets the IP, then caches it for a while.
For troubleshooting, the useful part is that any step can be the failure. If a name will not resolve, I check the configured resolver, try a known-good one like 8.8.8.8 directly, and see whether the record even exists. Caching also explains a lot of 'works for me but not for you' situations. Works by IP, fails by name is DNS almost every time.
Describing DNS as one lookup and missing the resolver chain and caching, which is where real problems live.
“A name resolves when you query 8.8.8.8 directly but not through the configured resolver. What does that tell you?”
A fundamental with real 'why it matters' reasoning.
TCP is connection-oriented and reliable, it sets up a connection, guarantees delivery and order, and retransmits lost packets. UDP is connectionless and has no delivery guarantee, but it is faster and lighter. You use TCP where correctness matters and UDP where speed matters more than perfection.
The tradeoff is reliability versus overhead. TCP's handshake and acknowledgments cost time, worth it for a file transfer but not for a live call where a slightly dropped packet matters less than lag. A nice detail: DNS uses UDP for normal small queries because it is fast, but falls back to TCP for larger responses.
Saying 'UDP is unreliable so it is bad,' missing that its speed is exactly why it is chosen for real-time traffic.
“Why does DNS use UDP for most queries but sometimes switch to TCP?”
Narrowing a partial failure, which is harder than a total outage.
Since everything else works, the user's general connectivity and DNS are probably fine, so I focus on the path to that one application. Can they resolve its name, can they reach its IP and port, is the app itself up, and can other people reach it or is it just this user.
'Just this user or everyone' splits it immediately: if others can reach the app, the problem is specific to this user or their path. If nobody can, the app or its server is the problem, not the network. I test the specific port, not just ping, because ping can succeed while the application port is blocked or the service is down.
Relying on ping alone and concluding 'the network is fine' when the specific application port is actually blocked or down.
“Ping to the app server succeeds but the application still will not connect. What does that suggest?”
The complete Networking Interview Prep Pack adds dozens more questions, deeper troubleshooting scenarios, follow-up questions, a quick-review cheat sheet, and a 7-day study plan.
Whether you actually understand subnetting, not just recognize the word.
A /24 has 256 addresses. To split it into four equal subnets I borrow two bits from the host portion, making them /26 networks, each with 64 addresses. You get four blocks: .0 to .63, .64 to .127, .128 to .191, and .192 to .255, each with 62 usable host addresses.
The reasoning is: four subnets needs two bits (2 squared is 4), and borrowing two bits from the host portion of a /24 extends the network prefix to /26. Each /26 has 64 total addresses, minus one for the network address and one for broadcast, leaves 62 usable. The reason to subnet at all is segmentation, smaller broadcast domains, and applying different security rules per segment.
Forgetting to subtract the network and broadcast addresses, or miscounting how many bits four subnets requires.
“How many usable hosts are in each subnet, and why is it not 64?”
Understanding of a service that quietly underpins most networks.
DHCP hands out IP configuration automatically. The device broadcasts a discover, the server offers an address, the device requests it, and the server acknowledges, the DORA process. If the pool is exhausted, new devices cannot get an address and fail to join the network.
When the pool runs out, the symptom is new devices cannot connect but existing ones are fine, because devices that already have a lease keep working until it expires. That is a useful diagnostic signal. Fixes are widening the scope, shortening lease times so addresses recycle faster, or finding whatever is consuming leases.
Not connecting 'pool exhausted' to the specific symptom of only new devices failing.
“New laptops cannot get on the network but everyone already connected is fine. What is your first guess?”
A core concept that explains how home and office networks actually reach the internet.
NAT, network address translation, lets many devices on a private network share one public IP address. The router translates between the private addresses inside and the public address outside, keeping track of which internal device each connection belongs to.
The reason it is everywhere is that there are not enough IPv4 addresses for every device to have a public one. A side effect is that it acts as a rough barrier, outside hosts cannot directly initiate connections to an internal device without a rule, which is why port forwarding exists. IPv6 reduces the need for NAT, but IPv4 plus NAT is still the common reality.
Confusing NAT with a firewall; it provides some isolation as a side effect but is not a security control by design.
“If everything inside shares one public IP, how does an incoming connection reach a specific internal server?”
Practical protocol literacy, framed usefully rather than as rote memorization.
The ones I reach for constantly: 22 SSH, 53 DNS, 80 HTTP, 443 HTTPS, 25 and 587 for email sending, 3389 RDP. Knowing them helps because when I am checking whether a service is reachable, I know which port to test.
The reason ports matter is that 'the server is up' and 'the service is reachable' are different questions. If a web server is running but the site will not load, I check whether 443 is actually open and listening, because the host can be perfectly reachable while that one port is blocked or the service is not bound to it. Ports turn a vague 'it is down' into a specific, testable check.
Memorizing port numbers as trivia without connecting them to testing a specific port when a service is unreachable.
“A web server is running but the site will not load from outside. Which port do you check and how?”
These questions come from the free SecureByDefault curriculum. Go learn the underlying skills, or explore the scenarios these answers are built on.