Walk me through your troubleshooting methodology when a user reports "the network is down."

I start by checking what is fastest to verify rather than assuming it is a router problem from the outset. First I confirm scope: is it one user, one subnet, one site, or everything, since that alone rules out most of the network. I check physical layer status on the affected port or link, then verify Layer 2 with a ping to the default gateway, then Layer 3 with a traceroute to see exactly where the path breaks. I pull recent change logs before touching anything, because in my experience a change made in the last 24 hours is the cause more often than a genuine hardware failure. Once I isolate the failing hop or device, I check its logs and interface counters for errors, drops, or CRC issues rather than guessing. I log every step as I go, both to keep myself honest about what I have actually ruled out and so the next person does not repeat my work.

How do you decide between OSPF and BGP for a given network design?

OSPF is my default for interior routing within a single organisation, since it converges fast, handles topology changes well, and does not require the policy overhead BGP carries. I use it inside a campus or data centre where all routers are under one administrative control and the goal is simply the shortest, most efficient path. BGP comes in once I am routing between autonomous systems: connecting to an ISP, peering with a partner network, or running a multi-site WAN where I need policy control over which paths traffic takes rather than just the shortest one. BGP also gives me path attributes like AS-PATH and local preference to engineer traffic deliberately, which OSPF cannot do. In practice I have run both together: OSPF internally, redistributed carefully into BGP at the edge, with route filtering so an internal routing change cannot accidentally leak into the internet.

How do you approach network documentation?

I keep three things current at all times: a topology diagram that reflects the actual live network, not the one from the original design; an IPAM system tracking every subnet, VLAN, and allocation so nobody double-assigns an address; and a change log tied to every configuration push, including who made it, why, and the rollback plan. I write runbooks for anything that happens more than once, especially incident response steps, so the fix does not depend on the memory of one engineer alone. I have seen outages take three times longer to resolve simply because the documentation did not match reality, so I treat updating it as part of finishing the change, not an optional follow-up task. I review the topology diagram against the live network quarterly to catch drift before it becomes a problem during an incident.

How do you use AI or automation tools in your network engineering work?

I use monitoring platforms with anomaly detection built in to flag traffic patterns or latency spikes that fall outside normal baselines, which catches issues before users report them. For repetitive configuration work, like pushing the same VLAN or ACL change across twenty switches, I use Ansible playbooks and Python scripts rather than doing it manually, which also cuts down on typo-driven outages. Where I do not hand off control is anything security sensitive or customer facing: firewall rule changes, BGP policy changes, and anything touching the internet edge get a manual review from me before they go live, regardless of how confident the automation is. I treat AI-assisted tools as good at pattern detection and repetitive execution, and treat my own judgment as the final check on anything that could take down a segment of the network.

Tell me about a time you diagnosed and resolved a major network outage.

During a core switch failure, an entire building lost connectivity, affecting around 400 users for what became a 45-minute outage. I confirmed the failure was isolated to that switch by checking that the redundant switch in the stack was still up but not passing traffic, which pointed to a spanning tree issue rather than a hardware failure. I checked the spanning tree topology and found a misconfigured priority value from a change made the day before, which had caused a loop that the protection mechanisms on the switch were fighting rather than resolving cleanly. I corrected the priority value, forced a spanning tree recalculation, and confirmed traffic was flowing normally within about six minutes of identifying the cause. Afterward I wrote up the incident, added a peer review step for any spanning tree priority change, and updated the runbook so the next engineer could recognise the same symptom faster.

Describe a time you had to explain a network issue to a non-technical stakeholder.

During a period of intermittent slowness affecting a sales team ahead of a big client call, the VP wanted an update every fifteen minutes and had no patience for jargon. I explained it as a traffic jam on one specific road between their office and the internet, not the whole network being broken, which set the right expectation that most systems were fine. I gave a plain timeline: we know where the congestion is, we are rerouting traffic around it now, and we expect it resolved within the hour. I avoided terms like packet loss or MTU and instead described what they would actually notice, like pages loading slowly versus not loading at all. When it was fixed, I confirmed with a specific before and after number: latency dropped from around 400 milliseconds to under 20, so they had something concrete rather than just my word that it was resolved.

Tell me about a time you were on call and had to handle an incident outside business hours.

I got paged around 2am for a BGP session flapping with our secondary ISP, which was intermittently dropping our backup internet path. It was not customer impacting yet since primary was still up, but flapping BGP sessions can escalate quickly if left alone. I logged in, checked the interface for physical layer errors, and found nothing locally, which pointed to a problem on the provider side. I opened a ticket with the ISP with the specific timestamps and error counters, dampened the session temporarily to stop the flapping from generating excessive log noise, and set a reminder to follow up in the morning if they had not responded. I documented the whole sequence in our incident channel so the team had context without needing to wake anyone else up. The provider confirmed a fibre issue on their end the next day, and I closed the loop by removing the dampening once the session stabilised.

Explain the difference between a VLAN and a subnet, and why you might use both together.

A VLAN is a Layer 2 construct: it segments broadcast domains within switches so that devices in different VLANs do not see the broadcast traffic from devices in other VLANs, even if they are physically connected to the same switch. A subnet is a Layer 3 construct, a logical grouping of IP addresses that determines how routing decisions are made. In practice I map one subnet to one VLAN as a standard convention, since it keeps troubleshooting simple: if I know the VLAN, I know the subnet, and vice versa. The reason to use both together rather than just one is that VLANs give me the physical and broadcast isolation at the switch level, while subnets give me the routing and access control boundary at the router or firewall level. For example, I might put finance and engineering on separate VLANs and separate subnets so I can apply different firewall policy to each without any ambiguity about which traffic belongs where.

How do you segment a network for security, and what is your approach to firewall rule design?

I design around zones based on trust level and function rather than physical location: a DMZ for anything internet facing, an internal zone for general corporate traffic, and a restricted zone for sensitive systems like finance or production databases. Traffic between zones has to pass through a firewall, and I write rules on a default deny basis, meaning nothing is allowed unless it is explicitly needed, rather than starting permissive and trying to lock things down later. Every rule gets a description of who requested it and why, since an undocumented rule is the hardest thing to remove safely two years later. I review the full rule set quarterly to remove anything that is no longer needed, since firewall rulesets tend to grow and rarely shrink without deliberate effort. For any new segment, I also think about east-west traffic, not just north-south, since a lot of real breaches spread laterally once they are inside a single trusted zone.

How do you approach networking in the cloud, like VPC peering, versus on-premises networking?

On-premises networking is largely physical: I am managing actual switches, cables, and hardware failure modes, and routing decisions are tied to physical topology. In the cloud, networking is defined in software: a VPC is a logically isolated network within a provider, and VPC peering lets two VPCs route traffic to each other privately without going over the public internet, but it is not transitive, so peering A to B and B to C does not let A reach C without a direct peering connection or a transit gateway. I have used transit gateways to hub multiple VPCs together instead of building a full mesh of individual peering connections, which gets unmanageable past a handful of VPCs. For hybrid setups I have configured both VPN and dedicated connections like Direct Connect back to on-premises, and the main design question is always the same: what is the latency and reliability requirement, since VPN over the internet is fine for backup paths but not for anything latency sensitive.

Network Engineer

Network Engineer interviews test how you diagnose connectivity issues under pressure, and how solid your fundamentals are in routing, switching, and security. Interviewers want to see a repeatable troubleshooting method, not just router configuration commands, along with how you document your work and support on-call rotations. This guide covers the questions asked most often and the answers that get offers.

For general interview preparation tips, read our guide to common interview questions.

Prepare further

How to ace the behavioural interview (STAR method)How to prepare for a technical interview

Common Network Engineer Interview Questions

Behavioural Interview Questions for Network Engineer Roles

Technical Questions for Network Engineer Candidates

What Hiring Managers Look for in Network Engineer Interviews

What hiring managers really look for in Network Engineer candidates:

A repeatable troubleshooting method. Strong candidates isolate scope and move through layers systematically instead of guessing at fixes.
Fluency across routing protocols with real judgment about when to use each, not just textbook definitions of OSPF or BGP.
Security instincts by default. Segmentation, default deny firewall rules, and documented change control should come up unprompted, not only when asked directly about security.
Documentation habits. Ask for a specific runbook or topology diagram they have maintained, since claims of good documentation without an example are weak.
Sound judgment about escalation during on-call incidents. Knowing when an issue can wait until morning is as valuable as technical depth.

Questions to Ask Your Interviewer

→What monitoring and alerting stack does the team use, and how much noise is in the current alerts?
→How is the on-call rotation structured, and what is the average number of pages per week?
→How much of the network is documented today, and how current is it?
→What does the change management process look like for a routine configuration push versus an emergency fix?
→How much of the infrastructure is on-premises versus cloud, and is that mix expected to shift?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free on your first tracked role.

Related Roles

DevOps Engineer

Tech9 questions

Cybersecurity Specialist

Tech9 questions

Systems Administrator

Tech10 questions

IT Support Specialist

Tech10 questions

Available in Other Languages

Français Español