Cohesyve · Practice for candidates
Preparing for a Network Engineer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Network engineering interviews are among the most technically direct in IT. You will be asked to explain how protocols behave, to troubleshoot a fault from a symptom, and to justify a design decision under questioning — often at a whiteboard with no documentation to hand. Employers do this because network faults are high-impact and time-critical, and because the difference between someone who has memorised commands and someone who understands the packet path becomes obvious under pressure. This page covers the stages you will meet and how to prepare for each.
The hiring process, stage by stage
Recruiter screen
Covers your vendor experience, the size and type of estate you have supported — campus, data centre, wide area, cloud — your certifications, and whether you have carried an on-call pager.
How to prepare: Prepare a concise description of your current estate: number of sites, device count in rough terms, vendors, and what you are personally responsible for. Be precise about certification levels rather than rounding up.
Technical screen
Rapid protocol questions, usually forty-five minutes. Expect subnetting on the spot, the difference between routing protocols, how a device decides where to send a packet, and spanning tree behaviour.
How to prepare: Drill subnetting until you can do it mentally in seconds, and be able to describe the full path of a packet between two hosts across a routed network, including ARP and MAC learning, without notes.
Troubleshooting scenario
A described fault — a site is down, an application is slow, a VPN flaps — and you must talk through your diagnosis. Scored on method and on which layer you start at, not on guessing the answer.
How to prepare: Practise narrating a structured approach aloud: what changed, what is the scope, which layer, what would confirm or eliminate each hypothesis. Have your first three commands ready for any fault type.
Design or whiteboard session
Design a network for a stated requirement — a new office, a data centre fabric, redundant connectivity between sites — with constraints on budget and availability. Common at mid-level and above.
How to prepare: Practise drawing a resilient topology with addressing, routing, redundancy and failure behaviour. Be ready to say what happens when each link or device fails, and to price the difference between two levels of redundancy.
Team and operational fit
With the team and often a manager. Covers change control, working an incident under pressure, documentation habits, on-call expectations, and how you handle a change that caused an outage.
How to prepare: Prepare an honest story about a change you made that broke something: what you missed, how you recovered, and what you changed in your process. Have a view on change windows and rollback planning.
What to study
Routing and switching fundamentals
This is the base layer of every technical screen. Candidates who have operated by following runbooks rather than understanding the protocols are exposed quickly here.
Troubleshooting method
Most of the interview weight sits here because it is most of the job. Interviewers listen for a repeatable method rather than an inspired guess.
Network security
Segmentation, firewalls and access control are now part of the core role rather than a separate function, and panels test whether you design with them in mind.
Automation and modern operations
Estates are increasingly configured through code and templates. Being purely command-line is now a limiting factor in many organisations.
Cloud and hybrid connectivity
Almost every estate now extends into at least one cloud provider, and hybrid routing is a common source of the faults you will be asked to diagnose.
Cohesyve for candidates
Practise a Network Engineer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Rebuild protocol depth, particularly in areas your current estate does not exercise.
- •Review OSPF and BGP behaviour to the point where you can explain path selection without notes
- •Drill subnetting daily until it is mental arithmetic rather than a calculation
- •Build a small lab, virtual or physical, and break things in it deliberately
- •Read the job advert for vendor and technology names you have not touched, and close those gaps first
Two weeks out
Practise narrating diagnosis, because silent troubleshooting scores nothing.
- •Work through fault scenarios aloud, stating your hypothesis and the command that tests it
- •Capture and read real traffic so packet-capture questions are familiar
- •Practise a whiteboard design for a two-site resilient network with addressing and failure behaviour
- •Rehearse the outage story until you can tell it without becoming defensive
The final week
Consolidate rather than add. Focus on recall speed and clear explanation.
- •Do one full mock covering protocol questions, a fault scenario and a design in sequence
- •Review your own estate's topology so you can describe it accurately from memory
- •Prepare short, clear definitions for the concepts you tend to explain clumsily
- •Confirm with the recruiter whether the technical stage is verbal, lab-based or a whiteboard
The day before and the day of
Rest. Recall speed drops sharply when tired, and these interviews are recall-heavy.
- •Run through subnetting and a single packet-path explanation once, then stop
- •Check your video and whiteboard tooling if the session is remote
- •Have paper for sketching topologies rather than describing them verbally
- •Plan to ask clarifying questions on any fault scenario before diagnosing
Questions to expect
“A user says the application is slow. Walk me through your diagnosis.”
What they're really asking: Do you have a method, and do you avoid assuming it is the network?
How to answer: Establish scope first: one user, one site, or everyone, and when it started. Then work from the endpoint outward — is it reachable, what is the latency and loss, is it DNS, is it the path or the server. Name the specific commands or captures you would use at each step and what result would move you on.
“Explain what happens when a host sends a packet to another host on a different subnet.”
What they're really asking: Do you understand the fundamentals, or have you memorised configuration?
How to answer: Go step by step: the host compares the destination against its subnet mask, resolves the default gateway MAC via ARP, frames the packet, and the router forwards on its routing table with a new layer two header at each hop. Mention TTL and the return path, since candidates commonly forget the return path exists.
“When would you use BGP rather than OSPF?”
What they're really asking: Do you understand the design intent of each protocol, or only that one is used externally?
How to answer: Frame it around scale, administrative boundaries and policy control: OSPF for fast convergence within an administrative domain, BGP where you need policy, multiple providers or a very large number of prefixes. Give a concrete case from your own estate where the choice was made and why.
“Tell me about a change you made that caused an outage.”
What they're really asking: Are you honest about failure, and did you improve your process afterwards?
How to answer: Pick a genuine one. State what you intended, what you missed in review or testing, how long recovery took, and precisely what changed afterwards — a rollback plan, a pre-change verification step, a peer review. Refusing to name one reads as either inexperience or dishonesty.
“Design connectivity for two new offices that must stay online if a link fails.”
What they're really asking: Can you design for failure and price the redundancy honestly?
How to answer: Clarify user counts, applications, acceptable downtime and budget first. Then present a topology with diverse circuits, routing that fails over predictably, and addressing that does not collide with the existing estate. Walk through each failure case and what users experience, and give a cheaper option with the trade-off stated.
“How do you approach automating configuration across the estate?”
What they're really asking: Are you moving with the field, or are you a command-line-only engineer?
How to answer: Start with what you would automate first — usually audit and state collection rather than configuration push, because it is low risk and immediately useful. Describe templating, version control and a staged rollout with verification. Be honest about your current level rather than overclaiming.
What to bring as evidence
A topology you designed or rebuilt, with the redundancy decisions and their costs
A significant incident you resolved, including the diagnostic path and the root cause
A migration or refresh you delivered, with the cutover plan and what went wrong
Any automation or scripting you have written, even small state-collection scripts
Current certification levels stated accurately, plus any lab work you do independently
Documentation or runbooks you produced that other engineers actually use
Common mistakes
Diagnosing silently and giving only the answer, which leaves nothing to score
Assuming the fault is on the network before establishing scope
Being unable to subnet quickly, which reads as a fundamentals gap regardless of experience
Describing configuration steps when asked to explain protocol behaviour
Designing without addressing plan, failure behaviour or cost
Refusing to name a change that caused an outage
Questions to ask them
- ?
What does the change process look like here, and when did it last stop a bad change?
- ?
How much of the estate is managed through automation versus device by device?
- ?
What is the on-call rotation, and how many out-of-hours incidents does it typically involve?
- ?
Where is the estate in its lifecycle — what is overdue for refresh and what is blocking it?
- ?
How does the network team find out about an application problem, and how often is it actually the network?
- ?
What is the split between project work and operational firefighting in a normal month?
Frequently Asked Questions
How much do certifications matter?
They still carry real weight in this field, more than in most IT roles, particularly at CV screening and in vendor-partner organisations. They will not carry you through a troubleshooting scenario, where the panel is listening for method. Keep them current and be precise about which level you hold.
Do I need to know automation to get hired?
For most mid-level and senior roles you need enough to collect state, compare configurations and make a repeatable change safely. Full infrastructure-as-code fluency is a differentiator rather than a requirement in the majority of estates. Being openly at the start of that journey is acceptable; dismissing it is not.
Will I be tested in a live lab?
Some employers use a lab environment where you must fix a broken configuration, others keep it verbal at a whiteboard. Ask the recruiter, because preparing for the wrong format costs you. If it is a lab, practise on the same vendor CLI rather than a generic simulator.
How do I show cloud networking experience if my estate is on-premises?
Build it yourself. A small virtual network with routing, a VPN back to a home lab and some DNS resolution across the boundary teaches most of what is tested and gives you something concrete to describe. Interviewers accept self-built experience here readily because the concepts transfer.
Is it possible to practise the technical stage before the real one?
Rehearsing under observation is the closest thing to the real conditions, and it is where most candidates find their pacing problems. Import the job into Cohesyve, run a network engineer simulation, and you will get a scored report on your troubleshooting method, protocol reasoning and design choices, with a pathway for the gaps. Your first three assessments are free, no card.
Practice
What a Network Engineer assessment tests, and how it's scored →
Career guide
What a Network Engineer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Network Engineer role? See how your applicants perform before you spend interview time.