Role: Network Administrator, office and branch networksFull interview loop

This loop is for an organisation with a head office and a few branches, users who mostly work in cloud applications, and a network run by one to three people who answer the tickets, make the changes and share an on-call rota. It assumes the person hired will own the switches, the Wi-Fi, the firewalls, the internet links and the VPNs, and will not have a network engineering team behind them to design what they then operate. Nothing in it depends on a vendor: each plan says what a command or a rule does and leaves the syntax to the interviewer's own equipment. It is not the loop for an engineer building a data-centre fabric or running routing with transit providers; that job needs a design round on routing, which this loop does not have.

The rounds follow the order in which work reaches a network administrator. The first is the phone: two scenarios run from evidence cards, a floor whose users keep dropping and an evening outage that the failover did not catch and the monitoring did not page. The second is the ticket three people have already looked at, a file copy that stalls in one direction only, captured in three places. The third is Saturday night: an approved change request, written by someone who has left, that would take two floors off the network, and then a decision at 23:41 with fourteen devices missing. The fourth is what seven years of requests leave behind: a firewall export with rules nobody owns, a new door-access system to place, and a plan for taking rules away.

Troubleshooting from evidence is read three times. Every candidate says they troubleshoot methodically, and one conversation cannot separate a method recited from a method used, so the three reads come at it differently: by what the candidate asks an interviewer holding the evidence to show them, by what they find in raw packets, and by what they conclude from a before-and-after table while a change window is open and a wrong answer means an unnecessary rollback. Change safety and segmentation are read twice each, and each second read changes the object: change safety on a configuration change and then on removing firewall rules; segmentation as the ICMP policy written after an outage and then as a rulebase and a new zone.

Monitoring and working with users and providers are read once, both in the first round, and monitoring is the choice most worth questioning. On a team of one, the administrator builds the monitoring as well as responding to it, and a hire who is weak there will keep hearing about outages from the phone before any alert fires. If your network's monitoring is thin, make Monitoring a must-have and give it a second question — the alerting for the door-access zone in the fourth round is a natural place. Two things are left out deliberately. Automation is not scored, which suits a network of a few dozen switches and not one of several hundred; for that, add a scripting round. And there is no behavioral round: how a candidate talks to a support centre's shift lead and to a provider's fault line is read inside the evening-outage scenario, where it happens. The Behavioral Interview plan for this title is there if you also want stories from past jobs.