Network Engineer Interview Questions

"I started on a service desk, and the tickets I liked most were the ones where a whole floor couldn't print or a site was offline, because they made me follow the path end to end. I built a small lab at home with a couple of used switches and a router, and within a year I moved into the network team. Since then I've looked after a campus of about a dozen access switches, two core switches and three branch offices linked by site-to-site VPNs. I handle VLAN changes, firewall requests and first-line troubleshooting, and I've done two branch refreshes myself. Next I want more ownership of routing and design, not just the day-to-day changes, which is why this role appeals to me."

"What drew me in is that you run a mix of campus, branch and cloud connectivity, and the job ad mentioned moving branches to SD-WAN. That's the kind of project I want to be part of. Before my first on-call week I'd want to see the current diagrams, even rough ones, and know how much they can be trusted. I'd ask what monitoring exists and what alerts actually wake people up, how changes get approved, and which parts of the network have caused the most trouble recently. I'd also want read access to the devices early and a walk through the last few incident reports. That tells me more about how the network really behaves than any design document."

"The parts I use every week are VLANs, trunks and subnetting. I've set up access and trunk ports on real switches, and I've planned address ranges for new floors. I've also written and fixed access lists on routers and firewalls, which taught me far more than the study guide did about rule order. What I haven't touched in production is BGP. I understand how it works and I've built it in a lab with two virtual routers peering over a private link, but I've never had to run it with an internet provider. I've been reading real configs from our edge routers and asked my lead if I can shadow the next change there, because I'd rather learn it next to someone than on my own at night."

"I write it in the ticket first, then talk it through, because a verbal handover at the end of a long night loses detail. I cover the current state, who's still affected, and anything temporary I left in place, like a shut port or a temporary route, so nobody mistakes it for the design. Then what I've tried and ruled out, with the evidence, so they don't repeat it. Then what I'd do next, and who we're waiting on, like a provider ticket number. I also make sure they have the access they need before I log off. If I'm the one receiving, I read it back in my own words, because that's where the gaps show up."

"I'd say what I know and what I don't, in plain words. Something like, core and firewall links are up, and I'm not seeing drops toward the affected servers, but I haven't ruled out the load balancer yet. I'm checking that now and I'll update you in ten minutes. That's more useful than saying it's definitely not the network, which I might have to take back later, and it's better than going quiet. Managers on those calls mostly want to know that someone is on it and when they'll hear more. If they push for a cause I don't have, I'd say I'm not sure yet rather than guess, because a wrong guess can send the whole team the wrong way."

"A VLAN splits one physical switch network into separate broadcast domains, so the finance PCs and the phones can sit on the same switches but act like separate networks. Traffic between VLANs has to go through a router or a layer 3 switch. An access port belongs to one VLAN and sends frames untagged, because the laptop or printer on it doesn't need to know about VLANs. A trunk carries several VLANs between switches, or to a router or hypervisor, so each frame gets an 802.1Q tag with the VLAN number. The exception is the native VLAN, which travels untagged. Both ends must agree on it, and I usually set it to an unused VLAN and limit the trunk to only the VLANs it needs."

"Ethernet frames have no time-to-live, so if two switches are joined by two links with nothing stopping it, broadcasts go round forever and the network melts. Spanning Tree builds a loop-free tree by blocking redundant links. It elects a root bridge first, and the lowest bridge ID wins, which is the priority value and then the MAC address. Every switch ships with the same default priority, so the lowest MAC decides, and that's often the oldest access switch in a cupboard. Then all traffic bends toward it. So I set a low priority on the core switches, a primary and a backup, per VLAN. I also turn on PortFast with BPDU guard on user ports, so they come up fast and shut down if someone plugs in a switch."

"I start with a survey, because walls, glass and how many people sit in an area matter more than floor size. I design for capacity, not just coverage, especially in meeting rooms. On 2.4 GHz, in most regions only channels 1, 6 and 11 don't overlap, so I use those. Most clients should be on 5 GHz, which has many more channels, and in a dense office I keep channel width narrow so neighbouring access points don't share airtime. I don't run access points at full power, because then clients cling to a far one instead of roaming to a closer one. For security, staff use WPA2 or WPA3 Enterprise with 802.1X, and guests get a separate SSID on an isolated VLAN. I keep the number of SSIDs small, since each one adds overhead."

"A loop gets worse by the second, so I stop it before I study it. If the switch CLI is sluggish, I use the console. I look for MAC address flapping messages in the logs, which point to the ports where the same address keeps moving, and check which interfaces have huge broadcast counts. If a change or a new connection happened recently, that's my first suspect. I shut the port that looks responsible, or if I can't tell, I cut the affected access switch off its uplink so the rest of the network recovers. Then I trace it, often to a small unmanaged switch or a cable plugged back into the wall. Afterwards I check that BPDU guard and storm control are on for every user port, so next time the port shuts itself."

"I use static routes where the network is small and doesn't change, like a branch with one way out, or a default route toward the internet provider. They're simple and predictable, but they don't notice when something far away breaks, and they don't scale once you have lots of sites. Dynamic protocols like OSPF learn routes and reroute on their own when a link fails, so I use them anywhere there's more than one path. A floating static route is a backup. I give it a higher administrative distance than the main route, so it stays out of the routing table until the main route disappears. A common case is a default route over a 4G link that only takes over when the route learned over the main circuit is lost."

"Inside a company network, OSPF is my default. It's an open standard, so it works across vendors, every router builds the same map of the links and works out shortest paths, and areas let you keep a large network tidy, with area 0 as the backbone. EIGRP does a similar job with less configuration and fast failover, but you mostly see it on networks that are Cisco end to end, so I'd keep it where it already runs rather than bring it into a mixed network. BGP is different. It's for exchanging routes between separate networks, like with internet providers or a cloud provider, and it gives you fine control over which paths you prefer and what you advertise. Big data centres also use it internally because it scales and is easy to control."

"I start with the neighbour state, because it narrows things fast. If the other router doesn't show up at all, hellos aren't getting through, so I check the link is up, the interface isn't passive, and no access list is dropping OSPF multicast. If hellos arrive but they're ignored, the fields that must match are wrong: the area ID, the subnet and mask on the link, the hello and dead timers, authentication, and the area type, such as one side set as a stub. Duplicate router IDs cause odd failures too. If they get stuck in ExStart or Exchange, it's almost always an MTU mismatch, because they can't swap their database descriptions. And if two routers sit in 2-Way on a shared segment, that's normal when neither is the designated router."

"First, if any of them were more specific, the longest match would win regardless of where it came from. But here the prefix is identical, so the router compares administrative distance, which is how much it trusts each source, and lower wins. On Cisco defaults, a static route is 1, eBGP is 20 and OSPF is 110, so the static route goes in the table. The others stay in their own protocol tables as backups. Metrics like OSPF cost don't matter here, because you can't compare a cost with a BGP path; metric only decides between routes from the same protocol. Other vendors use different default values, and some call it route preference, so I always check the platform before relying on the numbers."

"I size each need first. A hundred users need a /25, which gives 126 usable addresses. Fifty phones fit a /26 with 62 usable. Twenty printers fit a /27 with 30 usable. The link needs two addresses, so a /30, or a /31 if both ends support it. Then I place them largest first so the boundaries line up. Users get 10.20.30.0/25, hosts .1 to .126. Phones get 10.20.30.128/26, hosts .129 to .190. Printers get 10.20.30.192/27, hosts .193 to .222. The link gets 10.20.30.224/30, with .225 and .226. That leaves .228 to .255 spare. Each subnet also loses one address to its gateway, so the user subnet only has room for about 25 more people. If the branch is growing, I'd ask for a second block now."

"Static NAT is a fixed one-to-one mapping, so an inside address always appears as the same public address, and outside hosts can start connections to it. Dynamic NAT hands out addresses from a public pool on a first-come basis, one per inside host, which is rare now because public addresses are scarce. PAT, sometimes called overload, lets hundreds of hosts share one public address by translating the source port as well, and that's what I'd use for staff browsing. For the web server I'd use a static mapping, and ideally only for the ports it needs, like 443, which is static PAT or port forwarding. That way the rest of the server isn't exposed, and the firewall policy still has to allow the traffic on top of the translation."

"The router checks each line from the top and stops at the first match, so order matters: a broad permit near the top makes everything under it useless. At the end there's an implicit deny, so anything not matched is dropped, which catches people out when they add an ACL to block one thing and cut off everything else. A standard ACL only looks at the source address, so if I put it near the source it would block that host from everywhere, not just the one place I meant. That's why it goes close to the destination. An extended ACL can match source, destination, protocol and port, so I put it close to the source and drop unwanted traffic before it crosses the network. Each interface takes one IPv4 ACL per direction."

"My first thought is that the request and the reply are taking different paths. A stateful firewall only lets a reply through if it saw the session start. So if traffic goes out through the firewall in data centre A and comes back through the one in B, firewall B sees a reply for a session it knows nothing about and drops it. Pings can still get through if ICMP is allowed both ways, and with equal-cost paths some flows happen to return the same way and work, which is why it looks random. I'd prove it with traceroutes from both ends and look at firewall B's logs for TCP packets dropped because no session exists for them. The fix is to make routing symmetric, for example by adjusting route preferences so each flow uses the same firewall both ways, or to run the firewalls as a cluster that shares session state."

"I don't want to be the reason the launch slips, so I'd start by asking what the vendor system actually needs to talk to. Usually a quick call with the vendor gets me the source addresses, the destination servers and the ports. Then I can write a narrow rule that's just as fast to put in as an any-any rule. If they genuinely don't know the ports yet, I might allow the two specific hosts to talk, log everything, and set an expiry of a few days so I can tighten it from the logs. It still goes through our change process, even as an emergency change. If they still want any-any, I'd explain the risk plainly and ask for sign-off from whoever owns security risk, rather than quietly doing it."

"A site-to-site VPN joins two networks through their gateways, so users at the branch don't do anything, the tunnel just carries their traffic. A remote access VPN connects one person's device, so it needs per-user login, ideally with MFA, and a choice between full tunnel and split tunnel. For an IPsec site-to-site tunnel, both ends must agree in two stages. In phase 1 they set up a secure channel, so the IKE version, encryption, integrity, Diffie-Hellman group and the authentication, a pre-shared key or certificates, have to match. In phase 2 they agree how to protect the actual traffic, so the ESP encryption and integrity settings and PFS must match, and the local and remote networks must be exact mirror images. Between the peers I also need UDP 500 open, plus UDP 4500 if there's NAT in the path, or ESP itself if there isn't."

"With a traditional WAN, each branch hangs off a provider's MPLS network, and routing and changes are done box by box. SD-WAN builds encrypted tunnels over whatever links a site has, like broadband, 4G and MPLS, and manages them from a central controller. The big change is that it measures loss, delay and jitter on each path and steers applications to the best one, so voice can move off a link that's struggling while backups use the cheaper line. New sites can also come up with little hands-on setup. What it doesn't fix is a poor underlay: if both links at a site are bad, the overlay can't invent quality. Internet links don't come with the same guarantees as a private circuit, and you still need a proper security design."

"Hosts only know one default gateway, so if that router dies they're stuck. HSRP and VRRP fix that by having two routers share a virtual IP address and virtual MAC address, and hosts point at the virtual IP. One router is active, or master in VRRP, and answers for it, while the other listens for its hellos. If the hellos stop, the standby takes over the virtual address and hosts carry on without changing anything. Priority decides who's active. Preemption means that when the higher-priority router comes back, it takes the role back; in HSRP that's off by default and in VRRP it's on. I also use interface tracking, so if the active router loses its uplink, its priority drops and the other router takes over. HSRP is Cisco's protocol, VRRP is the open standard."

"The transfer fills the WAN link and the voice packets wait behind it, so they arrive late or get dropped. First I make sure voice is marked, usually DSCP EF, set by the phone and trusted at the access port, or marked at the switch if I can't trust it. Then on the branch router's WAN side I put voice in a priority queue with a cap, so it goes first but can't starve everything else, and share the rest fairly. The key detail is shaping to the real circuit speed. If the port runs at a gigabit but the circuit is much slower, the queue builds up in the provider's gear where my policy does nothing. What QoS can't do is create bandwidth: if calls alone fill the link, I need a bigger circuit."

"CRC errors mean frames are arriving damaged, so this is almost always physical or a duplex problem, and the retransmissions are what users feel as slowness. First I check both ends. Errors only count on the receiving side, so the side that shows them tells me which direction is damaged. On copper, I check speed and duplex on both ends; a mismatch shows as CRC errors on the full-duplex side and late collisions on the half-duplex side. Otherwise I suspect the patch lead, the cable run or a failing port. On fibre, I check the optic's light levels, since a dirty connector or a bent fibre often shows up as low receive power. I clear the counters so I can see whether they're still rising, then swap one part at a time and watch again."

"First I scope it. Is it just this user, their whole floor, or everyone? Is it only this app? And what changed recently? That usually halves the search. If it's one user, I check their address, mask, gateway and DNS, because a wrong VLAN or a stale address is common. Then I follow the path. Can they reach their gateway? Does the app's name resolve to the right address? Can they open the actual port, not just ping, since ping being blocked tells me nothing? A traceroute shows how far traffic gets. Then I check firewall logs and ACL hit counts for drops, and routing on the devices along the way. If the network path is clean, I go to the app team with evidence, like the connection reaching the server and getting no reply."

"At my last company, one morning a branch lost access to every head office system, although local internet worked. I was the on-call engineer. The site-to-site tunnel showed as up, which confused people, but traffic counters on our side showed packets going in and nothing coming back. I checked the tunnel details and saw phase 2 had re-keyed overnight and only one of the two network pairs had come back. The branch firewall had a slightly different definition of our head office subnets after an earlier change. I cleared the tunnel so it renegotiated, which fixed it in minutes, then corrected the network definitions so both ends mirrored each other. Afterwards I added monitoring that tests traffic through the tunnel, not just its status."

"Our finance team said a reporting app was slow because the network was bad, and it had been escalated to my manager. Instead of arguing, I took a packet capture between a user's PC and the app server while someone ran a report. The network round trip was a couple of milliseconds, with no drops or retransmissions. The server acknowledged the request straight away, then took about forty seconds before sending any data back. So the time was being spent inside the server, not on the wire. I sat down with the app team, showed them the capture, and they found a database query that had slowed down after a data growth spurt. I kept it friendly by framing it as helping them find the cause, not proving I was right."

"The decision should already be made in my change plan, which says when I stop trying and roll back, with enough time left to finish the rollback. Rolling back a core switch isn't instant, so with forty minutes left I'd probably give myself a few more minutes of focused checks, and if it still isn't clean, I roll back. Before touching anything, I'd have saved the running config and made sure the old software image is still on the switch. I'd tell the change manager and whoever is on call what's happening, then do the rollback and run the same checks I ran before starting: interfaces up, routing neighbours up, key services reachable. Then I'd collect the logs and error output, open a case with the vendor if needed, and book a new window."

"Early on, I was asked to add one VLAN to a trunk between two switches. I typed the allowed VLAN command without the word add, which replaced the whole list with just the new VLAN. Every other VLAN on that link dropped straight away, and the phones and PCs on that floor went offline. Monitoring lit up within a minute, I spotted the missing word in my own command, and I put the full list back from the saved config. The outage was a few minutes, but I told my lead straight away and wrote it up. Since then I write every change as a script beforehand, have someone review it, save the running config first, and for anything on uplinks I schedule an automatic reload or rollback in case I cut myself off."

"At my last job we backed up switch configs by hand once a month, which meant after most outages we had an old copy at best. I wrote a Python script that logged into every device nightly with a read-only account, saved the running config, and committed it to a git repository. That gave us a daily history and a diff of every change, and more than once it showed us a change nobody had logged. Later I built a script for access port VLAN changes, which were our most common ticket. To keep it safe, it first showed exactly what it would change, only touched ports marked as user ports, ran on one switch before the rest, and saved the config first. Changes that used to take twenty minutes of typing took two."

"When I joined my last company, the only diagram was three years old and several switches had default names. I didn't change anything for the first couple of weeks. I pulled configs from every device, used neighbour discovery and MAC and ARP tables to build an actual map of what connected to what, and labelled the cables in the comms rooms. The first real risk I found was that the Spanning Tree root was an access switch in a side office, so I planned a change to move it to the core. Then I named devices consistently, wrote descriptions on every uplink and set up config backups. By the end of the quarter we had a diagram people trusted and a short runbook for each site."