Interview guide · Technology roles
Network engineer interview questions
In short
Strong network engineer interview questions test whether a candidate understands how traffic actually moves (switching, routing, NAT, DNS), can troubleshoot layer by layer during an outage, makes changes safely with a rollback plan, and secures the network without breaking it. Below are 32 questions for network engineers, administrators and technicians, with answers to listen for and a scorecard.
Network engineers own the plumbing everything else depends on, so their mistakes are rarely small. A typo in an access list or a routing change on a Friday afternoon can take down a call center, a warehouse's scanners or every remote worker at once. The role needs solid fundamentals (the OSI model in practice, VLANs, spanning tree, routing protocols, NAT, firewalls), a disciplined approach to change, and calm, layered troubleshooting when users say 'the network is down' and it may or may not be.
Use these questions for network engineers, network administrators and network technicians, adjusting depth by level. For a technician, focus on the opening, fundamentals and troubleshooting groups. For an engineer, add design and change questions. For a senior or lead, add the final group. Ask the core questions of every candidate for the same role, let them draw or describe topologies, and score against the scorecard right after the interview. Follow-up questions ('and if that looks fine, what next?') separate real understanding from memorized answers faster than anything else.
What to look for in a network engineer
- Fundamentals that go below the command lineEngineers who understand ARP, MAC tables, routing decisions and NAT can solve problems they've never seen. Those who only know commands get stuck when the output looks unfamiliar.
- Layered troubleshootingWorking up or down the stack (physical, link, network, transport, application) and isolating the fault domain is how outages get fixed quickly instead of by guesswork.
- Change safetyMost network outages are self-inflicted. Pre-checks, maintenance windows, peer review, timed rollbacks and post-checks are signs of an engineer you can trust with production.
- Security awarenessSegmentation, least-privilege firewall rules, secure management access and logging are part of network design, not an add-on owned by someone else.
- Documentation habitsUp-to-date diagrams, IP plans and config backups cut outage time and make the network supportable by others.
- Communication across teamsNetwork engineers often have to prove it's not the network, or admit it is. Clear evidence and plain explanations keep server, security and application teams working together.
Opening questions
Describe the largest network you've supported: sites, users, main vendors and what you personally owned.
- Why ask it
- Establishes scale and real responsibility.
- A strong answer
- Specific numbers, vendors and platforms (campus, data center, WAN or SD-WAN, wireless, firewalls, cloud networking) and a clear line between what they designed, ran or just touched.
- Red flags
- Can't describe the network beyond the brand names.
Which piece of network work are you proudest of?
- Why ask it
- Shows depth and what motivates them.
- A strong answer
- A concrete project, such as a WAN migration, wireless redesign or segmentation rollout, with the problem, their approach, the result and what they'd do differently.
- Red flags
- Only routine tasks, or can't explain their own contribution.
How do you stay current with networking, and which certifications have you earned or are working on?
- Why ask it
- Checks learning habits.
- A strong answer
- Names relevant certifications (CCNA, CCNP, JNCIA, Network+, vendor firewall or cloud networking) and labs, simulators or real projects that back them up.
- Red flags
- Certifications with no hands-on application, or no learning at all.
What do you enjoy least about network work, and how do you handle it?
- Why ask it
- Honest answers reveal fit with on-call, documentation or vendor management.
- A strong answer
- A specific dislike handled maturely, such as cabling audits or after-hours changes, with how they still do it well.
- Red flags
- Dislikes core parts of the job they'd be doing daily.
Networking fundamentals
A laptop plugs into a switch port and opens a website. Walk me through what happens on the network, step by step.
- Why ask it
- The single best test of end-to-end understanding.
- A strong answer
- Link comes up, DHCP lease (discover, offer, request, acknowledge), ARP for the gateway, DNS query, TCP handshake, TLS, routing through the gateway, NAT at the edge and the return path. Mentions VLAN assignment or 802.1X if relevant.
- Red flags
- Skips layers or confuses DNS, ARP and DHCP.
What's the difference between a switch and a router, and where does a layer 3 switch fit?
- Why ask it
- Basic but reveals clarity of thought.
- A strong answer
- Switches forward frames by MAC within a broadcast domain; routers forward packets between networks by IP. A layer 3 switch routes between VLANs in hardware, typically without the WAN and advanced edge features of a router.
- Red flags
- Can't explain broadcast domains.
Why do we use VLANs, and how does traffic get between them?
- Why ask it
- Segmentation is everywhere.
- A strong answer
- Separate broadcast domains for security, performance and organization; trunk ports with 802.1Q tags; inter-VLAN routing on a layer 3 switch, router or firewall, with filtering where needed.
- Red flags
- Thinks VLANs alone provide security.
What problem does spanning tree solve, and what goes wrong when it's misconfigured?
- Why ask it
- Layer 2 loops still cause major outages.
- A strong answer
- Prevents loops by blocking redundant paths; root bridge election; faster variants such as RSTP. Misconfiguration causes broadcast storms or poor paths. Mentions BPDU guard and portfast on edge ports.
- Red flags
- Has never heard of a broadcast storm.
Compare OSPF and BGP. When would you use each?
- Why ask it
- Tests routing protocol understanding for engineer-level roles.
- A strong answer
- OSPF is a link-state interior protocol for fast convergence inside an organization; BGP is a path-vector protocol for routing between autonomous systems, ISPs and often SD-WAN or cloud, with policy control through attributes.
- Red flags
- Can't say why BGP is used for internet edge routing.
Explain NAT and PAT, and a problem NAT can cause.
- Why ask it
- Common at every edge.
- A strong answer
- Translates private to public addresses; PAT maps many inside hosts to one address by port. Problems include breaking some protocols (SIP, IPsec without NAT traversal), complicating logging and overlapping address spaces after mergers.
- Red flags
- Can't explain why private addresses aren't routed on the internet.
How does DNS fit into network troubleshooting?
- Why ask it
- Many 'network is down' reports are DNS.
- A strong answer
- Tests name resolution separately from reachability (ping an IP versus a name), checks which DNS servers clients use via DHCP, and looks for split DNS or conditional forwarding issues on VPN.
- Red flags
- Treats DNS as someone else's problem entirely.
What's the difference between TCP and UDP, and why does it matter for voice and video?
- Why ask it
- Relevant to call centers and any real-time traffic.
- A strong answer
- TCP is connection-oriented with retransmission; UDP is connectionless with lower overhead. Voice and video use UDP because a late packet is useless; quality depends on latency, jitter and loss, which QoS helps manage.
- Red flags
- Says voice uses TCP for reliability.
Troubleshooting questions
Users on one floor say the network is slow. How do you troubleshoot?
- Why ask it
- Vague complaint, real-world method.
- A strong answer
- Defines slow (which apps, wired or wireless, since when), checks interface errors, utilization and duplex on the access and uplink ports, looks for loops or broadcast storms, checks Wi-Fi channel use and client counts, and compares with monitoring baselines.
- Red flags
- Reboots the switch first.
A remote site has lost connectivity to headquarters. What do you check, in order?
- Why ask it
- WAN outages are a core responsibility.
- A strong answer
- Confirms scope, checks the circuit and provider status, edge device reachability via out-of-band access, interface and tunnel status, routing tables and BGP or IPsec state, recent changes, and opens a carrier ticket with evidence.
- Red flags
- No mention of recent changes or out-of-band access.
VoIP calls in the contact center have choppy audio at peak times. What do you look at?
- Why ask it
- Tests QoS and real-time traffic knowledge.
- A strong answer
- Measures jitter, latency and packet loss, checks QoS markings and queuing end to end, link utilization at peak, wireless versus wired agents, and remote agents' home connections.
- Red flags
- Blames the phone vendor without data.
A user can ping a server by IP but not by name. What's wrong?
- Why ask it
- Quick fault-isolation test.
- A strong answer
- DNS: wrong DNS server, missing record, stale cache, or split-DNS issue; checks with nslookup or dig and the client's configured resolvers.
- Red flags
- Starts checking cabling.
Which tools do you reach for first when troubleshooting, and why?
- Why ask it
- Shows practical toolkit.
- A strong answer
- Ping and traceroute, show commands for interfaces, ARP, MAC and routing tables, packet captures with Wireshark or tcpdump, flow data, monitoring dashboards and logs. Explains when a packet capture is worth it.
- Red flags
- Only knows ping.
Tell me about the hardest network problem you've solved.
- Why ask it
- Depth and persistence.
- A strong answer
- Clear description of symptoms, wrong turns, evidence that led to the cause, the fix and what they changed afterwards.
- Red flags
- Can't recall details or credits luck entirely.
Security, change and design questions
How do you plan and run a change on a core switch or firewall?
- Why ask it
- Change safety is the top predictor of reliability.
- A strong answer
- Written plan with pre-checks, exact commands, a maintenance window, peer review, config backup, a timed rollback (such as commit confirmed or reload in), post-checks and stakeholder communication.
- Red flags
- Makes changes live with no backup or rollback.
How would you segment a network that has a flat /16 with everything on it?
- Why ask it
- Common real-world remediation.
- A strong answer
- Inventories devices and flows, defines zones (users, servers, voice, IoT, guest, management, payment systems), migrates in phases, uses firewall rules between zones with logging, and tests each phase.
- Red flags
- Proposes a big-bang cutover without discovery.
What's your approach to firewall rule management?
- Why ask it
- Rule sprawl is a security and outage risk.
- A strong answer
- Least privilege, documented business owner and ticket per rule, naming standards, regular reviews to remove unused rules, logging, and avoiding any-any rules.
- Red flags
- Adds rules without review and never removes them.
How do you secure management access to network devices?
- Why ask it
- Device compromise gives attackers the network.
- A strong answer
- Dedicated management network or out-of-band, SSH only, centralized authentication (TACACS+ or RADIUS) with MFA where possible, role-based access, logging, disabled unused services, and patched firmware.
- Red flags
- Shared local admin passwords and Telnet.
How would you design Wi-Fi for a warehouse with handheld scanners?
- Why ask it
- Tests wireless design and business awareness.
- A strong answer
- Site survey, accounting for metal racking and inventory changes, coverage at scanner height, roaming behavior, 2.4 versus 5 GHz support on devices, SSID and VLAN design, and testing with real scanners.
- Red flags
- Places access points by guesswork.
How do you approach remote access for a workforce that's half remote?
- Why ask it
- Common in call centers and enterprises.
- A strong answer
- Compares full-tunnel and split-tunnel VPN or zero trust network access, sizing, MFA, device posture checks, and monitoring user experience.
- Red flags
- Only considers one approach with no trade-offs.
Behavioral and situational questions
Tell me about a time a change you made caused an outage.
- Why ask it
- Honesty and learning.
- A strong answer
- Owns the mistake, explains the rollback, communication and process changes afterwards.
- Red flags
- Has never made a mistake or blames others.
The application team insists a problem is the network. You believe it isn't. What do you do?
- Why ask it
- Cross-team collaboration.
- A strong answer
- Gathers evidence (captures, latency data, flow logs), shares it openly, offers to help find the real cause, and stays collaborative.
- Red flags
- Argues without data or refuses to help.
You find an undocumented device on the network. What do you do?
- Why ask it
- Security instinct and process.
- A strong answer
- Identifies it through MAC, switch port and vendor lookup, checks with facilities and security, isolates if suspicious, and documents.
- Red flags
- Ignores it, or unplugs critical equipment without checking.
A business leader wants a change made today that you think needs a maintenance window. How do you handle it?
- Why ask it
- Balancing urgency with risk.
- A strong answer
- Explains the risk in business terms, offers the earliest safe window or a lower-risk interim step, and escalates through the change process if it really is an emergency.
- Red flags
- Does it immediately to avoid conflict.
Questions for senior network engineers
How would you approach automating network configuration?
- Why ask it
- Senior engineers should reduce manual changes.
- A strong answer
- Starts with config backups and templates, then tools such as Ansible or Python with Netmiko or vendor APIs, version control, testing in a lab, and gradual rollout.
- Red flags
- No interest in automation.
How would you evaluate moving from MPLS to SD-WAN?
- Why ask it
- Common strategic decision.
- A strong answer
- Considers application requirements, cost, circuit diversity, security integration, vendor lock-in, operations skills and a pilot-site plan.
- Red flags
- Decides on vendor marketing alone.
What would you put in network documentation for a new team member?
- Why ask it
- Tests standards leadership.
- A strong answer
- Physical and logical diagrams, IP plan, VLAN list, routing design, firewall zones, vendor and circuit contacts, runbooks and change history.
- Red flags
- Says the config files are the documentation.
How do you plan network capacity for a site that will double its headcount next year?
- Why ask it
- Forward planning.
- A strong answer
- Uses utilization trends, per-user and application estimates, switch port and PoE budgets, wireless density, WAN bandwidth, and lead times for circuits and hardware.
- Red flags
- Waits until users complain.
Sample answers
Once the link is up, the switch learns the laptop's MAC on that port and puts it in the access VLAN, or assigns one after 802.1X if we use it. The laptop sends a DHCP discover, gets an offer and ends up with an IP, mask, gateway and DNS servers. To reach anything off its subnet it ARPs for the gateway's MAC. When I type a URL, it asks DNS for the IP, then opens a TCP connection with a three-way handshake to port 443 and negotiates TLS. Packets go to the gateway, get routed toward the edge, where the firewall checks policy and NATs the source to our public address. The response comes back through the same NAT state to the laptop.
I write the change up first: why, the exact commands, what I'll check before and after, and how I'll roll back. Someone else on the team reviews it, and it goes into a maintenance window that the affected teams know about. Before I start, I back up the running config and capture things like the routing table and interface states so I can compare after. On platforms that support it I use a commit with automatic rollback, so if I lose access the change reverts on its own. After the change I run the same checks, test a few key applications with the app owners, and only then close the change with notes on anything unexpected.
Choppy at peak tells me congestion is likely, so I'd start with data rather than guesses. I'd look at jitter, latency and loss from the call platform's quality reports and match them to times and agents. Then I'd check utilization on the uplinks and WAN at those times, and whether voice traffic is marked correctly and actually landing in a priority queue on every hop, not just at the edge. I'd also split the reports by wired, wireless and home-based agents, because the fix is very different for each. If it's home agents, the answer may be their ISP or Wi-Fi, and we'd give them guidance or a wired setup.
Interview scorecard
| Competency | Weight | Strong (4–5) | Weak (1–2) |
|---|---|---|---|
| Networking fundamentals | 25% | Explains end-to-end traffic flow, switching, routing, NAT and DNS accurately and can reason about unfamiliar cases. | Memorized commands with gaps in how things actually work. |
| Troubleshooting method | 25% | Defines scope, isolates layer by layer, uses the right tools and evidence, and fixes root causes. | Guesses, reboots, or can't describe the order of checks. |
| Change management and reliability | 15% | Plans, peer-reviews, backs up configs, uses timed rollback and verifies after changes. | Live changes without backup, rollback or communication. |
| Security and design | 15% | Segments by zone, keeps firewall rules lean and owned, secures management access, designs for real requirements. | Flat networks, any-any rules, insecure management. |
| Documentation and automation | 10% | Keeps diagrams and IP plans current, uses templates and scripts with version control. | Knowledge lives in their head; every change by hand. |
| Communication and collaboration | 10% | Shares evidence calmly, explains clearly to non-network teams, owns mistakes. | Defensive, dismissive of other teams, or unclear. |
Score each competency from 1 to 5 straight after the interview, before discussing the candidate with anyone else, then multiply by the weight.
How to structure a network engineer interview
For most network roles, three steps over one to two weeks is enough:
- Recruiter screen (20 minutes). Confirm vendors and platforms used, on-call and after-hours change expectations, travel to sites, certifications and salary range. Check the candidate's experience against the requirements in your network engineer job description, not just job titles.
- Technical interview (60 minutes) with a senior engineer. Start with the 'laptop opens a website' question, then two troubleshooting scenarios relevant to your environment, a change-management question and a security question. Allow whiteboarding or a shared diagram tool.
- Practical and team round (60 to 90 minutes). A lab task (fix a broken VLAN trunk, read a routing table, find the problem in a firewall config, analyze a packet capture), then behavioral questions with the manager and a peer from a neighboring team such as systems or security.
For technician roles, shorten the technical round and lean on fundamentals plus a hands-on cabling or switch configuration exercise. An online skills assessment on subnetting and basic configuration can screen technician applicants before you spend engineer time on interviews.
Mistakes interviewers make
Asking only certification-style trivia. Subnet math matters, but someone who can recite administrative distances may still freeze during an outage. Mix one or two quick fundamentals checks with scenario questions.
Not testing change discipline. Ask every candidate how they run a change. It predicts more about your future outage count than any protocol question.
Overlooking the cross-team piece. Network engineers who can't work with server and security teams create long, tense incidents. Include someone from the system administrator or security team in the panel and borrow a question or two from our cybersecurity interview questions if the role owns firewalls.
Hiring for the vendor, not the skill. A strong engineer who knows one vendor's syntax will learn another quickly. Weak fundamentals take much longer to fix.
Hiding the on-call and change-window reality. If changes happen at 11 p.m. on Saturdays, say so early.
Hiring network staff for large rollouts
Network refreshes, new contact center sites and managed service contracts can require several technicians and engineers at once. To keep quality consistent, pick a fixed set of questions for each level, write anchored ratings for each, and use the same lab exercise for every candidate. A short asynchronous technical screen with recorded answers to two or three scenario questions helps recruiters filter large applicant pools before engineers spend time on interviews.
Technician roles are a good pipeline from the help desk. Candidates who already troubleshoot connectivity tickets and are studying for a networking certification often outperform external hires with more years but less curiosity. Track which sources and interview scores predict good performance at six months, and adjust the question set based on what you learn.
Frequently asked questions
What are common network engineer interview questions?
Expect to explain what happens when a device connects and opens a website, compare switches and routers, describe VLANs and spanning tree, compare OSPF and BGP, troubleshoot a slow or down site, and explain how you plan and roll back a network change.
What questions are asked in a network administrator interview?
Network administrator interviews focus on day-to-day operation: switch and firewall configuration, VLANs, DHCP and DNS, Wi-Fi, VPN, monitoring, backups of device configs, and troubleshooting user connectivity issues.
What networking interview questions should a network technician expect?
Basic fundamentals such as IP addressing and subnetting, the difference between a hub, switch and router, DHCP and DNS, cabling standards, and a simple troubleshooting scenario like a user who has no network connection.
Do network engineer interviews include a practical test?
Often. Common formats are a lab configuration task, reading a routing table or firewall config, analyzing a packet capture, or a whiteboard design exercise. They typically take 30 to 60 minutes.
How important are certifications in a network engineer interview?
Certifications such as CCNA or CCNP show baseline knowledge and commitment, but interviewers care more about explaining concepts, troubleshooting logically and making changes safely.