Interview Prep
24 questions across the four roles on the career ladder: each with a model answer and, more usefully, what the interviewer is actually listening for.
These are not scored, and they are not scripts
An interview answer is spoken, it runs to several sentences, and its quality is in the reasoning, so nothing here can be marked automatically, and this page does not pretend to. Read the question, answer it out loud first, then open the model answer and see what you left out. Reciting these back word for word will sound exactly like what it is.
Help Desk / IT Support
First line. You are being tested on how you narrow a problem, not on how much you know.
A user calls and says “the internet is down.” What do you ask first?
Not a technical question yet: a scoping one. Is it just you, or the people around you? Is it every site or one site? Wired or wireless? Can you reach anything internal, like the file share or the intranet? Each answer removes half the possible causes, and two or three of them usually point straight at the layer to look in.
What they are listening for: Whether you narrow before you guess. Candidates who immediately say "I would restart the router" are answering a question nobody asked. The job is triage.
What is the difference between an IP address and a MAC address?
A MAC address is burned into the network interface and only has meaning on the local segment: switches use it to decide which port to send a frame out of. An IP address is assigned, it identifies a host on a network, and it is what routers use to move traffic between networks. The practical difference: a MAC address never crosses a router, an IP address does.
What they are listening for: That you understand layers as a division of labour, not as a list to recite. The "never crosses a router" line is the part that shows you have actually thought about it.
A laptop has the address 169.254.14.7. What does that tell you?
That it asked for a DHCP address and never got one, so it assigned itself a link-local address instead. It is a symptom, not the fault. So I would check the obvious physical things first (is the cable in, does the port show link) then whether the DHCP server is reachable from that VLAN, and whether the scope has any addresses left.
What they are listening for: That you read 169.254 as a message rather than an address to fix. Saying "the DHCP request failed" instead of "it has the wrong IP" is the whole answer.
How would you work out whether DNS is the problem?
Try the name and the address separately. If pinging the IP works and pinging the hostname does not, name resolution is the thing that is broken, not connectivity. Then I would check what resolver the machine is actually using and whether it answers: nslookup against a known-good name will tell you both.
What they are listening for: The instinct to split one symptom into two testable halves. It is the same instinct the rest of the job runs on.
What does the default gateway actually do?
It is where a host sends anything that is not on its own subnet. The host compares the destination against its own address and mask; if it is local it sends it directly, and if it is not, it hands the packet to the gateway to deal with. That is why a wrong gateway looks like "the internet is down" while everything on the same floor still works.
What they are listening for: Whether you can connect a config field to a symptom. The last sentence is the one that lands.
A user asks you something you do not know the answer to. What do you do?
Say so, and say what I am going to do about it: that I will find out and come back with a time. Then actually come back, even if the answer is "still working on it". What I would not do is guess out loud at somebody’s desk, because a wrong confident answer costs more time than an honest pause.
What they are listening for: Nobody expects a first-line hire to know everything. They are checking that you will not bluff, because a bluffing technician generates work for everyone else.
NOC Technician
Alerts and escalation. They want to see you separate a real fault from a noisy monitor.
An alert fires saying a link is down. Walk me through your first five minutes.
First, is it real: does a second source agree, or is this the monitoring system having a moment? Then scope: what is behind that link and who is affected right now. Then look at the far end, because "down" from one side can be a port, a cable, an optic or the device itself. I would also check whether it is flapping rather than cleanly down, because that changes both the cause and the urgency. Then escalate with those facts rather than with the alert text.
What they are listening for: Whether you verify before you act, and whether you escalate with information. "I would raise it to the engineer" on its own is a weak answer; "I would raise it with what I have already ruled out" is a strong one.
What is the difference between a switch and a router?
A switch forwards frames within a broadcast domain using MAC addresses. It is how devices on the same network reach each other. A router moves packets between networks using IP addresses, and it does not forward broadcasts, which is why each of its interfaces is a separate broadcast domain. In practice the switch is what connects the floor and the router is what lets the floor talk to anything else.
What they are listening for: The broadcast-domain boundary. Anyone can say "layer 2 and layer 3"; the boundary is what shows you know why it matters.
What is an SNMP trap, and why not just poll everything?
A trap is the device telling the monitoring system that something happened, rather than the monitoring system asking. Polling has an interval, so a link that goes down and comes back between polls is invisible; a trap arrives when the event does. In practice you use both: traps for events, polling for the counters and trends you want to graph.
What they are listening for: That you understand push versus pull, and that you know why a NOC needs both. The flap-between-polls example is the one that shows real experience.
Ping to the server works, but the application will not connect. Where do you look?
Ping only proves the host is reachable at layer 3. It says nothing about whether the service is listening or whether the port is allowed through. So I would check the specific port rather than the host, then whether the service is actually running on the far side, then firewall or ACL rules along the path. It is also worth confirming the client is resolving the name to the address you think it is.
What they are listening for: Whether you know the limits of your own tools. "Ping works" is the single most over-trusted piece of evidence in this job.
Why do changes happen in a maintenance window?
Because the point is to fail at a time you have chosen. A window puts the change where the fewest people are affected, where the right people are awake and available, and where there is enough time to roll back if it goes wrong. It also means the outage is expected: nobody is opening tickets for something you already know about.
What they are listening for: Whether you think about failure as a normal outcome to plan for rather than an accident. That mindset is most of what separates a safe operator from a fast one.
You escalate an issue and the engineer says it is not their problem. What now?
I would go back with evidence rather than with opinion: what I tested, what the result was, and what that rules out. Often the pushback is fair and I have handed it to the wrong team, and the evidence tells me who it should go to instead. If it genuinely is theirs, the same evidence is what settles it without it becoming an argument.
What they are listening for: How you behave when someone disagrees with you. They are hiring somebody who will be in the middle of exactly this, repeatedly.
Network Administrator
You own the config now. Expect questions about change, blast radius and recovery.
Why would you use VLANs instead of just more switches?
Three reasons that all matter. Broadcast containment, because every ARP and DHCP discover floods its own segment and a flat network of hundreds of hosts is permanently noisy. Security, because traffic between VLANs has to pass a router, which is where you can filter it. And flexibility, because a VLAN is not tied to physical location: finance can sit on three floors and still share one segment.
What they are listening for: Whether you give reasons or definitions. "A VLAN is a virtual LAN" answers nothing; the three reasons show you have designed with them.
Access port or trunk port: what is the difference?
An access port belongs to one VLAN and the device on the end has no idea VLANs exist; frames leave untagged. A trunk carries several VLANs between switches and tags each frame with 802.1Q so the far end knows which VLAN it belongs to. The one that catches people out is the native VLAN, which is sent untagged on a trunk: if the two ends disagree about it, traffic quietly ends up in the wrong place.
What they are listening for: The native VLAN. Mentioning it unprompted is a reliable signal that you have configured a trunk rather than just read about one.
How is an access list evaluated?
Top to bottom, and it stops at the first rule that matches: nothing below that line is ever considered. Anything that reaches the end without matching hits the implicit deny. That is why order is the whole game: a broad permit sitting above a narrow deny silently defeats it, and the same rules in a different order can allow or drop identical traffic.
What they are listening for: First match wins, and the implicit deny. Both are the difference between an ACL that works and one that looks like it should.
A subnet has run out of addresses. What are your options?
Depends what you can afford to disturb. Widening the mask is cleanest if the adjacent space is free, but it means renumbering and a change window. Adding a second subnet and routing between them avoids the renumber but adds a hop and a bit of complexity. Before either, I would check whether the pool is genuinely exhausted or just full of stale leases: shortening the DHCP lease time sometimes buys back a surprising amount.
What they are listening for: That you check the cheap explanation before doing the expensive work. The stale-lease answer is the one experienced people give first.
How do you make a change to production safely?
Back up the running config first, so rollback is a file rather than a memory. Know what "working" looks like before you start, so you can tell whether you broke it. Make one change at a time. Have the rollback written down before the change, not improvised after. And check it during the window, not the next morning.
What they are listening for: Whether rollback is planned or hoped for. "I would take a backup" is the minimum; "I write the rollback before the change" is the answer they want.
You make a change and something breaks. What is your first move?
Roll back, then diagnose. It is tempting to work out why while it is broken, but the users do not care why and the evidence will still be there afterwards. Then tell people: the person who reports their own mistake early is a lot cheaper to work with than the one who quietly tries to fix it.
What they are listening for: Restore service first, root cause second. And whether you will own it out loud, which is really what the question is for.
Network Engineer
Design and root cause. The questions get open-ended on purpose.
When would you use static routing over a dynamic protocol?
When the topology is small, stable and has only one way out: a branch office with a single uplink gains nothing from running a protocol, and a static default route is easier to reason about at 3am. Dynamic routing earns its complexity when there is more than one path, when the network is big enough that maintaining statics becomes its own source of outages, or when you need it to reconverge without a human.
What they are listening for: Whether you can argue for the simpler option. Candidates often assume dynamic is always the better answer, which tells the interviewer they have only worked at one scale.
A link in an OSPF network fails. What happens?
The neighbour goes away: either immediately if the interface loses carrier, or when the dead timer expires if the failure is less obvious. That router floods an updated LSA, every router in the area recalculates shortest paths with SPF, and a new route gets installed. The interesting part is the timing: carrier loss is near-instant, but a soft failure waits out the dead interval, which is why people tune those timers or lean on faster detection.
What they are listening for: The distinction between a link that drops and a neighbour that goes quiet. It is the difference between sub-second and forty-second convergence.
If OSPF works, why does BGP exist?
Because they solve different problems. OSPF finds the shortest path inside one administrative domain and assumes everyone is cooperating. BGP moves traffic between autonomous systems that do not trust each other, at a scale where flooding link state would be impossible, and it chooses paths on policy rather than on a metric. That is the real distinction: BGP is how you express "prefer this provider" or "do not carry that traffic", which is a business decision, not a distance.
What they are listening for: Policy versus metric. Reciting "IGP and EGP" is the memorised answer; policy is the understood one.
Design a network for a new three-floor office. Go.
I would ask before I draw. How many people per floor and what is the growth plan. What has to keep working if a switch dies, and what can wait until morning. What is on the network besides laptops: voice, wireless, cameras, card readers, each with their own requirements. Where does it connect to the outside and is there a second path. Only then does the design fall out: addressing plan with room to grow, VLANs by function rather than by floor, redundant uplinks to a core, and a management network that stays up when the rest does not.
What they are listening for: Whether you ask questions. An open design prompt is almost always a test of requirements-gathering, not of whether you can name a topology. Candidates who start drawing immediately fail it.
Users report a problem you cannot reproduce. How do you approach it?
Stop trying to reproduce it and start trying to catch it. Get specific about when: time of day, which users, which direction, does it correlate with anything scheduled. Put monitoring or a capture where it will be running when it next happens. Intermittent usually means something is loaded, timing out, or flapping, and all three leave traces even when you are not watching.
What they are listening for: Patience and instrumentation over guesswork. Also whether you will go and gather better data instead of theorising from a vague ticket.
Tell me about a time you were wrong about a technical decision.
Pick a real one, say what you believed and why it was reasonable at the time, say what changed your mind, and say what you do differently now. Do not pick something trivial to look safe, and do not pick something catastrophic to look dramatic. The answer is not about the mistake, it is about whether new evidence actually moves you.
What they are listening for: Whether you can be corrected. Senior people spend a lot of time disagreeing with each other, and an engineer who cannot update is expensive to work with.
How to actually use this
Say the answer out loud before you open it. Reading a good answer feels like knowing it, and the gap between those two things is exactly what an interview finds. If you can only manage a sentence when the model answer runs to four, that is the useful signal, not the fact that you recognised the topic.
The approach questions matter more than people expect. Most candidates prepare the technical ones and improvise the rest, which is why “tell me about a time you were wrong” is where interviews are lost rather than in the routing questions.
What each role actually does
The career ladder describes the four roles day to day, with a lesson to taste each one. If a question above assumed something you have not met yet, that is the page to go to.