RehearseAI
Networking interviews have an unusual property: the questions barely change from year to year, and candidates still fail them. Not because the material is hard, but because knowing how something works and explaining it aloud to a skeptical senior engineer are different skills.
Nobody gets hired for reciting the OSI model. People get hired for saying "the symptom you are describing sounds like MTU, and here is how I would prove it in five minutes".
Here are the questions that come up, what each is really for, and the traps.
The fundamentals they will definitely ask
"What happens when you type a URL and press enter?"
The most-asked networking question in existence, and the best one. It is not a memory test — it is an invitation to show how deep you go. DNS resolution, the TCP handshake, TLS negotiation, the HTTP request, the response, rendering. Then, if you want to stand out, mention where it usually breaks in practice: DNS caching, and TLS on a misconfigured certificate chain.
"TCP versus UDP — and when would you actually choose UDP?"
Everyone can list the differences. Fewer can name a real use: voice and video, where a retransmitted packet arrives too late to be useful, so dropping it is better than waiting. DNS queries, because a single small round trip does not need a handshake.
"Explain subnetting. What is a /24?"
Expect a small calculation. Know that a /24 gives 256 addresses with 254 usable, and be able to work out a /26 without a calculator. This is the question people most regret not practicing, because doing arithmetic aloud under mild pressure is genuinely harder than doing it alone.
"What is the difference between a switch and a router?"
Layer 2 versus layer 3 — forwarding within a network by MAC address versus between networks by IP. Add a sentence about broadcast domains and why VLANs exist and you have said everything they wanted.
"Walk me through DHCP."
Discover, offer, request, acknowledge. Then the practical part: what happens when there is no DHCP server, and why a device ends up with a 169.254 address.
"What is NAT and what does it break?"
Address translation is easy. The valuable half is knowing what it complicates — inbound connections, some VPN protocols, and end-to-end visibility for troubleshooting.
The troubleshooting question, which is the real interview
At some point somebody will describe a fault and watch you think. "Users say the intranet is slow, but only from the third floor." "One site can reach us; the other cannot." "It works over Wi-Fi and not over the cable."
The answer they want is a method, not a guess:
"I would start by narrowing the layer. Is it a physical or link problem, an addressing problem, a routing problem, or an application problem? I would check whether it fails by IP as well as by name — that separates DNS immediately. Then I would compare a working client with a broken one on the same segment and look for the first difference. I would change one thing at a time and write down what I changed."
Candidates who name the layer first, and who say "I would change one thing at a time", almost always do well here. Candidates who leap straight to "I would reboot the switch" do not.
Three things that make a strong impression
Saying "I do not know, here is how I would find out." Networking is enormous. Honesty plus a method beats a confident wrong answer every time.
Knowing your tools by name. ping, traceroute, dig or nslookup, tcpdump, and what each actually proves. Saying "I would look at a packet capture and check whether the SYN is being answered" is a sentence a bluffer cannot produce.
Having one war story. A real outage you helped resolve, told in two minutes, with what the cause turned out to be. It is the part they remember afterwards.
Say it out loud before the day
Every question above is one you could answer correctly on paper and still fumble in the room. Explaining a three-way handshake aloud, in order, without doubling back, takes one rehearsal.
Pick the URL question, the subnetting one, and the troubleshooting scenario. Answer each aloud in under two minutes. The first run will wander. The second will not, and that is the whole benefit.
If you want the follow-ups too, RehearseAI runs the interview for the role and asks the "and why that first?" questions a real engineer would. Every account gets one free 5-minute interview a month, no credit card required.
Quick answers
Do I need to memorize the OSI model? Know all seven layers and, more importantly, be able to use them to structure a diagnosis. That is what they are for.
How much do certifications matter? They get you past screening. The troubleshooting round is still where the decision is made.
Will there be a live lab? Sometimes, for network engineering roles. Ask the recruiter what the format is — they will normally tell you.
What if the role is cloud networking rather than traditional? The fundamentals still apply. Add VPCs, security groups, route tables and peering to the list above.
Sources
The technical ground here is the vendors' own documentation and the standards themselves; these are the pages I checked it against:
- CCNA certification — Cisco
- What is the network layer? — Cloudflare Learning Center
- What is DNS? — Cloudflare Learning Center
- RFC 1918: Address Allocation for Private Internets — IETF
If the interview turns behavioral, the STAR method is the shape to reach for. More on why I built this.
