Opens this plan in Hirezen, where one click makes it a position.
System Administrator interview questionsChange review — patch night round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Patching servers without breaking them: a monthly patch plan to review before it runs, the morning after it ran, and a database server someone wants reverted to its pre-patch snapshot — whether the candidate orders a change by what depends on what, checks services rather than compliance, and knows a snapshot is not a backup..
The plan, before it runs
What this section is for
Purpose
Runs over one patch night seen three times: the plan on Monday, the ticket on Wednesday morning, the rollback request on Wednesday afternoon. Hand over only the plan first. Write it to exactly this content, as circulated on Monday for Tuesday 22:00 to 02:00, covering 38 Windows servers, 6 Linux servers and 3 virtualisation hosts. 21:55, snapshot `SQL01`. 22:00, group A — `DC01`, `DC02`, `FS01`, `PRINT01` — install updates and restart. 22:00, group B — `SQL01`, `APP01`, `APP02`, `RDS01`, `RDS02` and the other 29 Windows servers — install and restart. 23:30, hosts `HV01` to `HV03` one at a time; running VMs move off each host automatically. 00:30, Linux servers: `dnf upgrade`, restarting only where `needs-restarting -r` says a restart is needed. Before starting, confirm that Monday night's backups of `SQL01` and `FS01` succeeded. Done when the patching console shows every server compliant; users are told at 08:00 on Wednesday. Rollback: `SQL01`, revert to the 21:55 snapshot; everything else, uninstall the update. The snapshot is deleted at next Tuesday's maintenance. Add three lines of context under the plan: the hosts have 512 GB of memory each, the running VMs are configured with 1,198 GB in total, and the cluster is set not to overcommit memory; the nightly backup jobs run from 01:00 to 03:30; the warehouse night shift works on `RDS01` and `RDS02` until 06:00. Seven things are wrong: the two domain controllers restart together; `SQL01` restarts at the same moment as the applications that need it; two hosts hold 1,024 GB, so the first host cannot be emptied; the database rollback is a snapshot kept for a week; "compliant" is the only test of success; the backups start while the Linux servers may still be restarting; and the warehouse loses its RDS servers at 22:00 without warning. Two lines are deliberately right and should be kept: the backup check before starting, and restarting Linux servers only when `needs-restarting` says so. Book 70 minutes; the close is outside the 60.
I'm [YOUR_NAME] and I run the servers at [COMPANY_NAME]. This hour follows one patch night from the plan to the day after. First the plan, as a colleague sent it round on Monday. Read it as the person who will be woken up if it goes wrong.
What this section is for
Purpose
Frames the review as ownership of the night rather than as proofreading, so the candidate reads for consequences instead of for wording.
Here is Tuesday's patch plan. Tell me what goes wrong if it runs as written, in the order it would hurt, and what you would change before Tuesday.
What this question is for, and what to listen for
Purpose
Reads patching and change control on a plan the candidate did not write. The separator is whether they reason from dependencies — what needs what to be running — rather than from a checklist of good practice.
Signals to score
- Splits the two domain controllers into separate slots and checks authentication and replication between restarts
- Restarts `SQL01` before the application servers and makes the applications' check wait for the database
- Does the capacity sum: two hosts give 1,024 GB against 1,198 GB of running VMs, so the first host will not empty and 23:30 stalls
- Rejects reverting a database server to a week-old snapshot as the rollback, or at least cuts the snapshot's life to hours and says what reverting loses
- Replaces "compliant in the console" with checks that services work — a sign-in, an invoice opened, a print job, an RDS session
- Notices the 01:00 backups begin while Linux servers may still be restarting, and moves one of them
- Finds the warehouse night shift on `RDS01` and `RDS02` and either reschedules those two or tells the shift in advance
- Stages the night in rings, with a small first group whose results decide whether the rest go ahead
- Keeps the backup check before starting and the `needs-restarting` rule, and says why they are right
- Says who is told what before the night and who is called if a step fails
Follow-up questions
- Both domain controllers restart at 22:00. What else stops working while they are down?
- Three hosts of 512 GB and 1,198 GB of running VMs. Walk me through 23:30.
- What does "compliant" in the console tell you about Wednesday at 09:00?
- Who is using these servers at 22:00?
- Which lines in this plan would you keep exactly as they are?
Wednesday, 08:40
What this section is for
Purpose
The plan ran exactly as written. Take the plan back and hand over the morning sheet, built from these facts. The ticket, 08:40: the invoicing application on `APP02` shows "Cannot connect to database" to everyone. The patching console: 44 of 47 compliant; `HV01` to `HV03` not attempted, because `HV01` timed out entering maintenance mode at 23:52. `DC01` restarted at 22:12 and `DC02` at 22:13; installs on 17 of the other Windows servers logged "cannot contact a domain controller" between 22:14 and 22:24 and succeeded when the console retried them at 22:40. `SQL01` restarted at 22:31, and the SQL Server service started at 22:47, after the update finished configuring. `APP02` restarted at 22:33; `InvoicingService` started at 22:35:02; its log says "database connection to SQL01 failed, retry 1 of 3" at 22:35:10 and "retry 3 of 3 failed, continuing without database" at 22:35:40; the service shows as Running. The backup report for 01:00: 39 of 44 VMs backed up; five Linux VMs failed with "guest restart in progress" and were not retried. The red herring: `APP02` logs a warning every hour that the certificate on its local management port expired in 2025, which has nothing to do with the database. A colleague has added a note: "uninstall last night's updates on APP02?"
Same plan, Wednesday morning. It ran as written. Here is what we know at 08:40.
What this section is for
Purpose
Makes the candidate carry the Monday review into the diagnosis, since the cause is one of the defects they were shown — and sees whether they notice.
Invoicing is down for everyone and finance has invoices to send. Using this sheet, tell me what happened, what you do in the next half hour, and what else last night broke that nobody has reported yet.
What this question is for, and what to listen for
Purpose
Reads troubleshooting from evidence after a change, where the reflex is to undo the change. The separator is whether the candidate builds the timeline across two servers before acting.
Signals to score
- Lines up the two servers' times and sees the application gave up at 22:35:40, eleven minutes before SQL Server started at 22:47
- Says "Running" was the wrong test, because the service is up and doing nothing useful
- Confirms `SQL01` is healthy — the service up, the database online, a test sign-in working — before touching `APP02`
- Restarts `InvoicingService` alone and confirms with a finance user that an invoice opens
- Declines to uninstall the updates or revert anything, and says why neither addresses the cause
- Sets aside the domain controller errors because the retries succeeded, and the certificate warning as unrelated, while noting both
- Asks which other applications started before something they depend on, and checks them before their users arrive
- Finds the five failed Linux backups and reruns them today
- Treats the three unpatched hosts as open work with a date, not as a finished night
- Records the timeline and feeds it back into the plan: database before applications, service checks, backups after patching
Follow-up questions
- The service says Running. Why does invoicing not work?
- Your colleague wants to uninstall last night's updates from `APP02`. What would that change?
- The console says 44 of 47. Which three, and does it matter today?
- What else might have started before the thing it needs?
- What did last night do to your backups?
Put it back how it was
What this section is for
Purpose
The afternoon sheet. 14:00 on Wednesday: invoicing has worked since 08:50 but is slow, and the finance manager asks for `SQL01` to be "put back how it was on Tuesday"; the plan's rollback line says revert to the 21:55 snapshot. The facts: the snapshot is still open and has grown to 142 GB; write latency on `SQL01`'s disks averaged about 4 ms last week and about 38 ms since 21:55 on Tuesday; `APP01`, on the same storage and patched the same night without a snapshot, is unchanged at 3 to 5 ms; 3,112 invoices have been created since 08:50; the database takes a full backup at 21:00 every night and a transaction log backup every 30 minutes, both written to `\\FS01\sqlbackup`, and all of them since Tuesday's full have succeeded, the last at 13:30. The red herring: last night's updates on `SQL01` included one for the database engine, which is the obvious thing to blame and is not what the storage figures point at.
The finance manager wants `SQL01` put back how it was on Tuesday, and the plan says revert to the snapshot. What do you tell them, and what do you actually do about the slowness?
What this question is for, and what to listen for
Purpose
Reads backup and recovery where it meets change: whether the candidate knows what a snapshot is and is not, and can separate undoing a patch from undoing a day of data.
Signals to score
- Says reverting to the 21:55 snapshot throws away everything written since, including the 3,112 invoices, and says so to the finance manager in those terms
- Separates rolling back the update from rolling back the data, and keeps the data
- Reads the latency figures and the unchanged `APP01` as pointing at the open snapshot rather than at the update
- Removes the snapshot at a quiet time, and warns that merging 142 GB loads the storage while it runs
- Confirms before removing it that last night's full backup and today's log backups exist and have been restored somewhere at least once
- Knows a point-in-time recovery of the database comes from the full and log backups, not from a VM snapshot
- Would remove the database update itself, rather than revert the server, if evidence later points at it
- Notes that a snapshot of a running database without the application's cooperation is only crash-consistent
- Changes the plan's rollback line and gives snapshots on servers an owner and an expiry measured in hours
Follow-up questions
- How many invoices does "how it was on Tuesday" throw away?
- Write latency jumped on Tuesday evening, and `APP01`'s did not. What happened to `SQL01` that did not happen to `APP01`?
- If the database update is the problem after all, what is the rollback that keeps the data?
- The snapshot is 142 GB. What happens when you remove it at 14:00 on a working day?
- What should the rollback line in the plan have said?
That is the whole night. Your turn: what would you want to know about how changes happen here — who approves them, what we check the morning after, how long our snapshots really live?
What this section is for
Purpose
Scores nothing and goes in the notes. A candidate who has been on the receiving end of a patch night tends to ask what is checked afterwards and who owns the plan.
One honest thing before you go: [say one true, current weakness in how your own team patches — a host cluster that cannot lose a host, a rollback nobody has tested, a server group that is always postponed]. You would be the one helping to fix it.
What this section is for
Purpose
Ends on a real fact about the team's own patching, which is the pitch this candidate needs and a warning to one who wants it already solved. Check it is still true on the day.
System Administrator interviews — common questions
- Who is this System Administrator interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the Change review — patch night round for a System Administrator role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the Change review — patch night round assess?
- This round is focused on: Patching servers without breaking them: a monthly patch plan to review before it runs, the morning after it ran, and a database server someone wants reverted to its pre-patch snapshot — whether the candidate orders a change by what depends on what, checks services rather than compliance, and knows a snapshot is not a backup.. It works through The plan, before it runs, Wednesday, 08:40 and Put it back how it was, scoring against 29 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- The plan, before it runs (20 min), Wednesday, 08:40 (22 min), Put it back how it was (18 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a System Administrator?
A single round does not cover a whole role. The other rounds in this library for a System Administrator: