M
Mechanism, Not Memorization
Anyone can recite "OSI has 7 layers." They're listening for whether you can trace what actually happens at each layer during a real failure — that's the difference between certification recall and operational experience.
↓
Structured, Bottom-Up Troubleshooting
A candidate who jumps straight to "maybe it's DNS" without ruling out physical/L2 first reads as guessing. They want to see a repeatable method, not a lucky guess.
Change control, rollback plans, and knowing when *not* to make a risky change under pressure — this is what separates someone safe to hand a live network to from someone who isn't yet.
◈
Communication Under Pressure
Can you explain a live outage to a non-technical stakeholder without either panicking or drowning them in jargon? This gets tested indirectly through how you narrate your answers, not just through a dedicated question.
Q A user can't reach a file server but can ping the default gateway. Walk through your approach.
A Confirm the symptom is real and scoped to this user/host first. Then work up the stack: ARP entry for the server present? Same VLAN or does it need routing? Any ACL/firewall rule between the segments? DNS resolving the right IP? Narrating this order, not just the final answer, is the actual signal.
Q Two switches show intermittent connectivity between them — where do you start looking?
A Interface counters for CRC errors or a duplex mismatch first — intermittent, not total, loss points at the physical/L2 layer before anything routing-related. Then check for recent STP topology changes on that link.
Q You see a broadcast storm hitting the network — what's your immediate action, and your follow-up?
A Immediate: identify and shut the port causing the loop to stop the bleeding. Follow-up: figure out why STP didn't block it — missing BPDU guard, a misconfigured trunk, or a rogue device — and fix the actual gap, not just the symptom.
Q A newly added VLAN isn't passing traffic between two switches. What do you check?
A Trunk's allowed-VLAN list on both ends, native VLAN mismatch, and — if VTP is in use — whether the VLAN actually propagated or is stuck in a different VTP domain/mode.
Q Routing to a remote site drops right after an unrelated change elsewhere. How do you isolate the cause?
A Check the routing table for the missing/changed route first, then whether redistribution between protocols broke, then confirm with traceroute exactly where the path now dies — "right after a change" is a strong hint it's not coincidental.
Q A link shows as "up/up" but no traffic is passing. What's your process?
A Interface being up only proves Layer 1/2 — check for a misconfigured VLAN/subinterface, an ACL silently dropping traffic, or a routing/next-hop issue above it. "Up/up but no traffic" is a classic prompt to test whether you know link state isn't the whole picture.
Q How would you design redundancy for a core switch pair?
A Redundant physical uplinks, HSRP/VRRP for a virtual gateway so end hosts don't need to know which switch is active, and spanning-tree tuned so failover is fast and predictable rather than left at defaults.
Q How do you approach capacity planning for WAN links before they become a problem?
A Baseline utilization trends over time rather than reacting to a single spike, and plan headroom against growth — capacity planning done reactively after complaints is already too late.
Q What's your process before pushing a config change to a production switch?
A Back up the current config, peer review the change if the environment supports it, apply in an agreed change window, and have a specific rollback step ready — not just "revert if it breaks."
Q A vendor releases new firmware for your core switches. How do you decide whether and when to upgrade?
A Read release notes for fixed/known bugs relevant to your environment, test in a lab or on a low-risk device first, then stage the production rollout with a clear rollback path — never push new firmware to the whole fleet at once.
Q How do you keep network documentation from going stale as the environment grows?
A Tie documentation updates to the change process itself — a change isn't "done" until the doc reflects it — rather than relying on a separate, easily-skipped documentation task.
Q How would you monitor for silent failures — things that break without triggering an obvious alert?
A Combine interface error-rate and utilization monitoring with synthetic checks (scheduled pings/traceroutes to key destinations) — a link that's "up" but degrading often shows in error counters before anyone notices manually.
Q Tell me about a time you diagnosed a genuinely hard-to-find network issue.
A Structure with STAR: the confusing symptom (Situation), what you were responsible for figuring out (Task), the specific troubleshooting steps that actually cracked it (Action), and the concrete fix plus what you changed afterward to prevent recurrence (Result).
Q Describe a time you pushed back on a requested change because you thought it was too risky.
A Show you can disagree professionally with data, not just gut feel — what specifically made it risky, how you communicated that, and what happened (did they proceed anyway, or did the plan change).
Q Tell me about a mistake you made that caused an outage. What did you learn?
A Own it directly — vague deflection here is a bigger red flag than the mistake itself. Then focus most of the answer on the concrete process change that came out of it.
Q Describe how you've handled being on-call for critical infrastructure.
A Talk concretely about triage speed, escalation judgment (when you called for help vs. handled it solo), and how you communicated status while still working the problem.
Q Tell me about a time you had to explain a technical network issue to a non-technical stakeholder.
A Show you can translate impact ("orders can't be processed") rather than mechanism ("BGP route flap") to the audience that needs it, while still being accurate.
Q Tell me about a time you disagreed with a teammate's technical approach.
A Focus on how the disagreement was resolved — data, a test, or escalation to a shared decision — rather than who was "right," and what the working relationship looked like afterward.