The 10 Hardest Network Engineer Interview Questions (and What Separates a Strong Answer)

Some interview questions are hard because they're obscure. The ones that actually separate candidates are hard for a different reason: the wrong answer and the right one sound almost identical for the first ten seconds, and only the follow-up question exposes which one you gave. These ten show up across BGP, firewalls, cloud networking, and live troubleshooting — not because they're rare, but because a correct-sounding non-answer is so easy to give on each of them.

1. Why Did This BGP Route Disappear — When the Path Is Clearly Still Up?

This question is designed to catch candidates who don't separate the BGP table from the routing table. A route can be received, valid, and present in the full BGP table while never being installed as the best path — because of a shorter AS path elsewhere, a higher local preference, a route-map silently filtering it, or AS-path prepending pushing it out of contention. A weak answer jumps straight to 'the neighbor must be down.' A strong answer checks the full BGP table first, not just the routing table, before concluding anything is actually missing.

2. A Session Between Two NAT'd Devices Won't Establish — Where Do You Look First?

The trap here is treating this as a routing problem when it's usually a state and translation problem. A strong answer starts with whether each firewall has a session entry for the flow at all, whether NAT is correctly attracting the return traffic to the translating device, and whether both directions of the conversation are traversing the same stateful device — because if the return path takes a different firewall that never saw the original session, the connection fails even though every device involved is configured correctly in isolation.

3. Two OSPF Neighbors Are Stuck in EXSTART or EXCHANGE — What Are Your First Three Checks?

Most candidates can define the OSPF neighbor state machine but freeze the moment they have to debug it live. The three checks that resolve this fastest, in order, are: MTU mismatch between the two interfaces, which is by far the most common cause and silently breaks database exchange without breaking the initial hello; a duplicate router ID somewhere in the area; and a network-type mismatch, such as one side configured as broadcast and the other as point-to-point on what should be the same logical segment. Naming MTU first, unprompted, is a strong signal you've actually hit this in production.

4. Design a Route Reflector Topology for 200 iBGP Routers Without a Single Point of Failure

This tests whether route reflection is understood as an architecture decision, not just a protocol feature. A strong answer organizes routers into multiple reflector clusters rather than one flat cluster of 200 clients, deploys at least two reflectors per cluster sharing a cluster ID for redundancy, and explains how ORIGINATOR_ID and CLUSTER_LIST prevent the redundant reflectors from creating routing loops between themselves — the exact mechanics that separate a candidate who has run route reflection at scale from one who has only read the definition.

5. Why Does Asymmetric Routing Break a Stateful Firewall Even Though Both Paths Are Valid?

Both paths can be individually correct and the connection still fails, because stateful inspection depends on the firewall that saw the first packet of a flow also seeing the return traffic. If the return path takes a different device — one that never built a session for that flow — it has nothing to match the traffic against and drops it. A strong answer explains this from the session-table side, not just the routing side, and knows to check path symmetry before assuming either firewall is misconfigured.

6. A Global Load Balancer Is Returning 502s in One Region Only — Walk Through It

The trap is jumping to application logs immediately. A structured answer checks backend health status for that region's backend group first, then capacity and balancing mode, then whether the region's load-balancer proxy infrastructure itself has exhausted capacity — a resource constraint that's easy to overlook because it lives at the infrastructure layer, below anything an application log would ever show.

7. Is a /31 Subnet Ever Valid, and Why Would Most Engineers Say No?

Most engineers are trained to treat any subnet without a usable host range as invalid, because a normal subnet reserves one address for the network and one for the broadcast, leaving zero usable addresses in a /31. RFC 3021 makes a specific exception for point-to-point links: because a point-to-point link only ever has two ends, both addresses can be used as host addresses, with no network or broadcast address reserved at all. It's a small fact, but it's a reliable way for an interviewer to find out whether a candidate has only memorized subnetting rules or actually understands why those rules exist.

8. "The Internet Is Slow" — With Only That Sentence, What's Your Investigation Sequence?

This question is deliberately under-specified, and that's the point. A weak answer starts guessing at causes. A strong answer scopes the problem first — one user, one site, or everyone; a specific destination or everywhere — before touching a single device, then compares against a known-good baseline, then isolates by layer working outward from the user. The candidates who ask good scoping questions before proposing a fix are the ones interviewers flag as ready to be on call.

9. When Would You Choose OSPF Over BGP Inside a Single Autonomous System — and When Would That Choice Be Wrong?

OSPF's fast convergence and simplicity make it the obvious first answer for interior routing, but the follow-up is where this question gets hard: at what scale does OSPF's flooding and SPF recalculation overhead become the problem, and when does an organization actually need BGP's policy control inside its own network — for traffic engineering between data centers, for example, or to avoid a full-mesh OSPF area design collapsing under its own complexity. A strong answer names a concrete scale or policy trigger, not just 'it depends.'

10. Walk Through What Actually Happens During a BGP Route Leak, and Which Controls Would Have Caught It

A route leak is a prefix being advertised to a peer that should never have received it — often an AS accidentally re-advertising a route it learned from one provider out to another, turning itself into an unintended transit path. A strong answer explains the mechanism first, then names the actual controls that catch it: prefix-length filtering, AS-path validation, RPKI origin validation, IRR-based filtering, and community tagging like NO_EXPORT — and is honest that RPKI validates origin, not the full path, so it doesn't catch every leak shape on its own.

None of these are hard because the underlying concept is rare — every one of them is standard curriculum. They're hard because the standard curriculum only gets you to the first sentence of a correct answer, and the interview is testing what you say next. My Next Hop's Routing Lab and Troubleshoot Sim modes run scenario questions across exactly these ten shapes, scored on the same reasoning depth an interviewer is actually listening for, not just whether the terminology was correct.