Network Administrator interview questionsChange review — a VLAN change for Saturday night round

Purpose

Gives the candidate ownership of someone else's approved change, which is the ordinary situation and the one where "it was approved" is most tempting as a reason to run it.

Purpose

The load-bearing question. Most candidates find something; the separator is whether they predict the consequence of each command on the night — including the one that cuts off their own access — and order by damage rather than by step number.

Signals to score

• Reads the allowed-list command in step 4 as a replacement, not an addition, before anything else
• Names what floors 3 and 4 lose when it runs: data, voice and access point management
• Works out that switch management goes too, so step 5 cannot be done remotely
• Notices the DHCP relay points at a server the IPAM extract no longer lists
• Explains that saving in step 6 makes the reload in step 8 restore the new configuration
• Says what reloading the core would do to the whole building
• Rejects pinging the gateway as verification, and notes there is no before-state to compare with
• Moves the start past the support centre's shift, or asks its lead
• Leaves the firmware upgrade out of this window, with a reason
• Compares the port map with step 5 and finds the 14 ports on the second stack member

Follow-up questions

• Step 4 on Po13. What exactly is still working on floor 3 a second later?
• You are at home on VPN. After step 4, which switches can you still reach?
• Step 6 then step 8. What does the reload give you back?
• The ping in step 7 succeeds. What have you learned?
• Why not do the firmware upgrade on IDF-4 while you're in there?

Purpose

Sets the deliverable as a rewritten change, not advice about changes, so the answer has to contain commands in an order, checks with numbers and an undo.

Purpose

Tests change safety at the level of the plan itself: whether the undo exists before the change does, whether access is protected, and whether "it worked" is defined in advance by counts rather than by feel.

Signals to score

• Captures the before-state with numbers: addresses per VLAN, registered phones, joined access points, uplink states
• Orders the work so nothing that carries management traffic changes first, and adds VLAN 60 to the core's list rather than replacing it
• Arms a confirm timer or scheduled revert before each change, and saves only after verification
• Writes out the exact undo commands, and has tried them on a spare switch or in a lab
• Arranges console or out-of-band access to both floor switches in case management is lost
• Corrects the DHCP relay to the current servers, with both addresses
• Defines verification from the devices' side: controllers leased, reaching the building-management server, and user counts unchanged
• Sets abort criteria as numbers agreed beforehand, such as any fall in phones registered
• Starts after the support centre's shift ends, and tells its lead
• Keeps the firmware upgrade out, and adds a peer check of the commands rather than of the form

Follow-up questions

• What's your undo if you can't reach IDF-4 at all?
• How do you get back without reloading the core?
• Which numbers do you write down at 23:00, and why those?
• At what point in the window do you stop trying and roll back?
• How would you know your rollback works before Saturday?

Purpose

Tests evidence-led troubleshooting under a change window's clock: reconciling three counts that disagree, locating the missing devices before touching anything, and making the call against the rules written for the window instead of against the mood at midnight.

Signals to score

• Uses the before-and-after table to confirm first that users are unaffected
• Reconciles 47 leases with 44 in the portal before assuming a second fault
• Works out that 61 minus 47 is exactly the 14 ports on the second stack member
• Asks for evidence of what is on those ports before changing them
• Reads the vendor prefix and VLAN 1 as the controllers sitting unassigned, not as something else
• Decides to fix forward because the change is inside the approved intent and the abort criteria are untouched
• Arms the revert again before touching IDF-4, and saves only after the count reaches 61
• Records the deviation in the change record, with what was changed and why
• Rechecks the portal after its refresh instead of treating 44 as a network fault

Follow-up questions

• The portal says 44 and the DHCP server says 47. Which do you believe?
• What's on 2/0/35–48 right now, and how do you know?
• Isn't changing ports that aren't in the approved request a change of its own?
• What would make you roll back instead?
• What do you write in the change record before you log off?

Purpose

A candidate who has run changes at night asks how rollback and review actually work; one who has not asks about the change-management tool. Naming the topics lets their choice be the signal.

Purpose

Ends on a specific weakness in the team's own change process: the honest pitch to the candidate this round is meant to find, and a warning to one hoping the process is already sound. Check it is still true first.