Most Linux networking interview prep focuses on definitions. What is DNS? What is a subnet mask? What is the OSI model? Those answers are worth about ten seconds of an interviewer’s time. The questions that actually predict whether someone has shipped a system on Linux are the troubleshooting ones, which most candidates have never practiced. The version of Linux we mean is current LTS distributions (Ubuntu 24.04, RHEL 9, Debian 12) using NetworkManager or systemd-networkd. The interview answers do not change much across distributions, but the commands do.
The foundational questions that filter out the unprepared
Three questions come up in almost every Linux networking interview, and they are the ones to rehearse first because they have no shortcut. The interviewer is not trying to trick you. They are trying to find out whether you have the vocabulary to discuss the rest of the interview.
The OSI vs TCP/IP question is the most common warm-up. The OSI model (a seven-layer reference model: Physical, Data Link, Network, Transport, Session, Presentation, Application) and the TCP/IP model (a four-layer practical model: Link, Internet, Transport, Application) describe the same network, but from different angles. The right answer is to explain that TCP/IP is the model that actually shipped and OSI is the model that academic courses still teach, and the layer numbers do not line up cleanly. If a candidate cannot sketch the two stacks side by side, the rest of the interview is going to be a struggle.
IPv4 vs IPv6 is the second warm-up. IPv4 gives about 4.3 billion addresses (2^32 minus reserved ranges), plenty in 1990 and out by 2015. IPv6 gives 2^128 addresses, a number nobody can visualize. The right answer is that IPv6 exists because IPv4 ran out, that NAT (Network Address Translation) extended IPv4’s life by a decade, and that IPv6 deployment is finally accelerating because mobile carriers and cloud providers have run out of workarounds.
Subnet masks are the third foundational question. A /24 subnet mask means the first 24 bits are the network portion and the remaining 8 bits are for hosts. 8 bits gives you 256 total addresses, but two are reserved (the network address and the broadcast address), so 254 usable. If you cannot do that math in your head on demand, you cannot troubleshoot a routing table, and that is the end of the network interview.
The protocol questions that test depth
Three questions move from definitions into protocol internals, and these are where the candidate who has read the chapter starts to fall behind the candidate who has shipped.
DNS is the first one. Everyone knows DNS resolves names to IP addresses. The interview question is what happens during a DNS lookup, and the right answer walks through the recursive resolver (the ISP or company DNS server that does the work on your behalf), the root nameservers (the 13 logical servers, mirrored at hundreds of physical locations, that serve the root zone), the TLD nameservers (the .com / .org / .country servers), and the authoritative nameserver for the actual domain. If the candidate does not mention TTL (Time To Live, the cache duration), caching, or the difference between recursive and iterative resolution, they have not actually debugged a DNS issue.
TCP vs UDP is the second protocol-internals question. TCP is connection-oriented and reliable (it establishes a session, retransmits lost packets, guarantees order); UDP is connectionless and fast (no handshake, no retransmits, no ordering). TCP is what HTTP, HTTPS, SSH, FTP, SMTP, and database connections use. UDP is what DNS, DHCP, SNMP, VoIP, online gaming, and live video streaming use. The modern wrinkle is HTTP/3, which runs over QUIC, which is built on UDP but provides reliable delivery because the latency savings of skipping the TCP handshake are worth the engineering complexity.
The TCP three-way handshake is the third protocol-internals question. The textbook answer is SYN, SYN-ACK, ACK (three packets exchanged to establish a connection). The interview answer is what each packet does, why the sequence numbers matter, and what happens if the ACK gets lost. The interview trap: if the candidate cannot explain that sequence numbers are random per connection to prevent TCP sequence prediction attacks, they have not looked at a packet capture.
The troubleshooting questions that test whether you have actually shipped
Four questions are the ones I lean on when interviewing for a Linux infrastructure role, and they are the questions most candidates have never practiced because the answers are not in any textbook.
DHCP is the first troubleshooting question. Most candidates can recite DORA (Discover, Offer, Request, Acknowledge), the four-step handshake a client uses to get an IP from a DHCP server. The interview answer is what happens when DHCP fails. The client falls back to a 169.254.x.x address (an APIPA / link-local address that signals “no DHCP found”), and if you do not know to look for that, you will spend twenty minutes chasing the wrong layer of the stack. The senior follow-up is what DHCP options matter for PXE boot (a network boot process where a diskless machine pulls its operating system over the network), VoIP, and IPv6.
The hub / switch / router question is the second troubleshooting question. Most candidates can recite the layer numbers (hub = Layer 1 / Physical, switch = Layer 2 / Data Link, router = Layer 3 / Network). The interview answer is what they actually do. A hub repeats every packet to every port. A switch learns MAC addresses and forwards only to the right port. A router connects different IP networks and decides which interface to send a packet out based on the routing table. The senior follow-up is what happens when a switch’s MAC table fills up, which is a real failure mode in older firmware.
The troubleshooting question that actually matters is the “a host cannot reach the internet” question. There is a four-step mental checklist that experienced Linux administrators use without thinking:
- Can the host ping its default gateway? If not, it is a Layer 1/2 problem.
- Can the host ping an external IP by address? If yes but DNS fails, it is a resolver config problem.
- Can the host reach services by name? If IP works but name does not, check /etc/resolv.conf and systemd-resolved.
- Can the host reach a specific service by IP and port? If not, it is a firewall or routing, and you start with iptables, nftables, and ip route.
That mental checklist is the single most useful artifact from a decade of Linux administration. If a candidate cannot produce some version of it, they have not done this work themselves.
What the good answers sound like
The difference between a senior and junior candidate usually shows up in how they hedge. The junior candidate says “I think it is the DNS server.” The senior candidate says “I would check /etc/resolv.conf first, then run systemd-resolve –status to see the upstream resolvers, then dig +trace example.com to see where the lookup is failing.” Specific commands and file paths are how senior candidates signal they have done the work.
The other senior tell is the willingness to say “I do not know.” Most senior Linux administrators I know have a short list of things they explicitly do not know off the top of their head: BGP path selection, the kernel’s TCP congestion control algorithms, the exact list of systemd-resolved’s cache TTLs. They say so, and then explain how they would find out (man page, –verbose flag, kernel source). The candidate who claims to know everything is the candidate who has not been wrong enough times to develop the habit of verifying.
What I would tell past me about Linux networking interview prep
If I could redo my own Linux networking interview prep, these four things would be higher on the list:
- Set up a two-host lab and break it on purpose. Spin up two VMs, give one of them a wrong subnet mask, and try to ping the other. The textbook explanation of subnet masks is fine; the five minutes you spend figuring out why ping returns “Destination Host Unreachable” instead of “Request Timed Out” is the lesson that actually sticks.
- Read a packet capture. tcpdump -i any -n host 8.8.8.8 while you run a curl https://example.com. The output is overwhelming at first, but after thirty minutes you can read a three-way handshake in the dump, and that is the foundation for everything else.
- Practice the troubleshooting question out loud. Have a friend describe a broken network and walk through your mental checklist. The first three times you do this, you will forget a step. The tenth time, it is automatic.
- Read the systemd-resolved man page once. systemd-resolved is the DNS resolver on every modern Ubuntu and Fedora system, and most candidates do not know it exists. Reading the man page once is a five-percent move in the interview that separates senior from junior.
Trade-offs
Linux networking interview prep is not free in time. The questions above cover roughly half of what an experienced interviewer might ask, and a serious candidate should plan on 30-50 hours of practice to cover the rest. The cost is real for people working full-time.
Interview prep is not free in scope creep. It is tempting to also study CCNA-level routing, BGP, and IPv6 deployment at carrier scale. For a Linux infrastructure role, most of that is out of scope. The most efficient prep is to spend 80 percent of study time on the questions above and reserve the rest for breadth.
Interview prep is not free in lab setup. The single best move is having a Linux machine you can break on purpose: a spare laptop, a VM, or a cloud instance. Without a lab, you are memorizing definitions, and definitions are the part of the interview that matters least.
For someone targeting a Linux networking role, this is a clear win: build a lab, rehearse the troubleshooting question, and drill the protocol internals until they come out without thinking. For someone interviewing more broadly, spend less time on each subsystem and more on the cross-cutting fundamentals.
Bottom line
If you have a Linux networking interview in the next two weeks, the highest-impact move is to set up a two-host lab today and practice the troubleshooting question until the checklist is automatic. None of the foundational questions take more than five minutes per question to rehearse. The difference between “I have read the chapter” and “I can read a packet capture” is the difference between passing the phone screen and getting bounced at the technical loop. The questions are not exotic. They are the ones your interviewer is going to ask first.