Network Administrator interview questionsScenario-based Questions round

Purpose

Sets the rules of the evidence cards before the first scenario, so asking for evidence is understood as the task rather than as stalling, and a candidate who reasons without asking has chosen to.

Purpose

Tests whether the candidate narrows the problem with the evidence the tickets already contain — one floor, wired and wireless, recurring at particular times — before asking for anything, and then asks for the evidence that separates layer 2 from layer 3 rather than reaching for the wireless controller because most tickets came from laptops.

Signals to score

• Reads the pattern in the tickets aloud before asking for a card: one floor, both media, clustered times
• Says early that wired and wireless dropping together points away from the radios and towards the shared VLAN or its gateway
• Asks for the gateway or ARP view within the first few requests rather than last
• Treats the radar event as explaining at most one ticket, and says why
• Rules out the uplink, the DHCP scope and spanning tree with the cards that show them clean, instead of assuming
• Connects the address-conflict messages to the ticket times before acting on them
• Traces the conflicting MAC to a switch port and a device before shutting anything
• Explains why "connected but nothing works" follows from a wrong ARP entry for the gateway
• Names a containment that is proportionate, such as shutting or moving one port, and says who has to be told
• Proposes a control that stops the class, such as DHCP snooping with dynamic ARP inspection, and names what it will break for statically addressed devices

Follow-up questions

• Nine of the fourteen tickets are from Wi-Fi laptops. Why not start at the wireless controller?
• The radar event at 11:02 matches a ticket at 11:04. What does it explain, and what does it not?
• Eleven tickets land just after the hour or the half hour. What kind of cause keeps a timetable?
• You have found the port. What do you do in the next ten minutes, and who hears about it?
• Dynamic ARP inspection is on your list. What breaks the day you turn it on?

Purpose

Puts the candidate at home, without a page and with users already affected, so how they get onto the network and what they say to the caller are part of the answer rather than an afterthought.

Purpose

Tests evidence-led troubleshooting under time pressure and the communication around it. The separator is whether the candidate notices that the failover's health check is testing the wrong thing — a probe that stays up is not proof the link works — and restores service before they have a root cause or a reply from the provider.

Signals to score

• Gets scope from the caller first: everyone or some, cloud tools only or phones too, since when
• Gives the shift lead a next-update time before hanging up
• Realises the VPN depends on the failed link and goes to the out-of-band console instead of trying it repeatedly
• Reads card 1 against card 2 and says the probe is up while traffic beyond hop 1 is dead
• Uses a ping sourced from the backup link to prove ISP-B works before failing over to it
• Dismisses the signature update with a reason drawn from the evidence rather than from instinct
• Forces the failover deliberately and says exactly what they change and how they will undo it
• Asks what depends on the office's public address before failing over, and warns the shift lead about ticketing logins
• Raises the fault with ISP-A with a circuit ID, a start time and the traceroute
• Checks from a user's point of view that service is back, not only that the route changed

Follow-up questions

• The probe says the primary link is up. Why don't you believe it?
• Your VPN goes over the link that is down. How are you getting in?
• A signature package installed seven minutes before the outage. Why isn't that your first suspect?
• You are about to move the office onto ISP-B. What stops working that was working before?
• What exactly do you tell ISP-A's fault line, and what do you ask them for?

Purpose

Moves from the incident to the instruments. Tests whether the candidate designs health checks around the failure that actually happens and gives alerting a path that does not depend on the thing it watches — the two reasons the on-call first heard of the outage from a phone call, fourteen minutes after the monitoring had seen it.

Signals to score

• Says the probe tested reachability of an on-site device rather than of the internet beyond it
• Proposes probing more than one target beyond the provider, sourced from the primary link, with the route withdrawn only when all of them fail
• Says the failover test tested a cable pull, and describes a test that simulates an upstream loss instead
• Explains that the notifications failed because they left through the same dead link
• Gives alerts a second path, such as SMS through the console server's modem or an external service
• Adds a heartbeat that pages from outside when the monitoring server goes quiet
• Wants an alert when the office is running on the backup link, since a silent failover hides the next failure
• Adds a check that looks like a user, such as loading a cloud login page, alongside the probes
• Fixes the dependencies the evening exposed: a VPN hostname with only one address and an allow-list with only one source

Follow-up questions

• Which targets would you probe, how often, and what makes you withdraw the route?
• How do you test this without waiting for ISP-A to break again?
• The monitoring server saw the outage at 19:38. What would have had to be true for your phone to ring at 19:39?
• If the office silently fails over to ISP-B at 3am, is that good news?
• The VPN hostname and the ticketing allow-list both assumed the primary link. What else here does?