Hiring for this role?
Start free with this planFree for your first open role.
Why Hirezen?
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
System Administrator interview questionsScenario-based Questions round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Sysadmin scenario questions with the evidence attached: a group change that did not take effect, domain logins failing on Linux, a caller asking for an MFA reset, an actively exploited vulnerability on a server finance depends on — whether the candidate reads what is on the page before acting, and knows which quick fix makes things worse.
Opening
Who is interviewing, how the round will run, and a question to settle the candidate in. The standard openingAdded to the group, still denied
What this part is for
Purpose
Four scenarios, each on one printed evidence sheet that you hand over when its section starts and take back when it ends; the candidate may write on it. Build this first sheet from these facts and nothing else. The ticket, logged Monday 09:40: Lena Brandt (`lbrandt`), a finance assistant, cannot open `\\FS01\Finance\Payroll`; the service desk added her to `FIN-Payroll-RW` at 09:05 and she still got "access denied" at 09:35. Her directory group list: Domain Users, FIN-Staff, FIN-Payroll-RW, CON-Contractors. `whoami /groups` run on her laptop at 09:36: Domain Users, FIN-Staff, CON-Contractors, and no FIN-Payroll-RW; her last sign-in was 08:41. The Payroll folder's permissions, written out in words rather than as tool output: an explicit Deny, Full control, for CON-Contractors, applying to the folder, subfolders and files; an explicit Allow, Modify, for FIN-Payroll-RW; and an inherited Allow, Read, for FIN-Staff. The share itself grants Change to Authenticated Users, which is deliberate — the folder permissions do the work. One line of history: she worked in the same team through an agency until 31 August and was hired on 1 September, and her contractor account was converted rather than replaced. The red herring: a note that the group change was made on DC02 while her laptop signs in against DC01. Both are in one site, so the change reached DC01 within seconds. There are two faults, and they are layered: fixing the first reveals the second. Book the room for 70 minutes; the close sits outside the 60.
I'm [YOUR_NAME] and I look after the servers, the directory and the backups at [COMPANY_NAME]. Nothing in this hour is a quiz about commands. You will get four sheets, each one a real kind of Monday, with the evidence someone has already gathered. I want to hear what you read on the page and what you would do, in that order.
What this line is for
Purpose
Tells the candidate the evidence is the material, so the first minute goes on reading rather than on reciting a troubleshooting method.
Here is the ticket and everything the service desk collected. Why can she not open the folder, and what do you change — for her today, and so that the next contractor we hire does not raise the same ticket?
What this question is for, and what to listen for
Purpose
Reads troubleshooting from evidence and whether the candidate understands how group membership reaches a file server. The separator is whether they predict the second failure before the first fix is applied.
Signals to score
- Compares the directory group list with `whoami /groups` and concludes her sign-in at 08:41 predates the change at 09:05
- Says the group list the file server uses was fixed when she signed in, so she needs a fresh sign-in, or new tickets and a reconnected share, before the new group counts
- Dismisses the DC01 and DC02 difference as a cause, with the reason
- Finds the explicit Deny for CON-Contractors and predicts she will still be denied after signing in again
- States that an explicit Deny on the folder wins over the Allow from FIN-Payroll-RW, whichever was added last
- Removes her from CON-Contractors instead of granting her own account an Allow on the folder
- Checks with the owner of the Payroll folder that write access is what she should have before testing
- Names the contractor-to-employee conversion as the step that left the group behind, and goes looking for other converted accounts
- Questions why a Deny entry exists at all and proposes access through allow-only role groups
- Tests as her, or with an effective-access check, before closing the ticket
Follow-up questions
- The directory says she is in FIN-Payroll-RW. Why does her laptop not agree?
- She signs out and back in. What happens now?
- Why not give her own account Modify on the folder and close the ticket?
- How does a permanent employee end up in CON-Contractors?
- Who else is in the same position, and how would you find them this afternoon?
Domain logins fail on the Linux servers
What this part is for
Purpose
The second sheet. The ticket, Monday 08:55: nobody can SSH into the web and batch servers with a domain account; the local break-glass account works; it worked on Friday. The change record: on Sunday between 14:00 and 16:30, fourteen Linux VMs and nine Windows member servers were moved from host cluster A to the new cluster B. From `web03`, at 09:12:00 by DC01's clock: `timedatectl` shows local time 09:04:31, "System clock synchronized: no" and "NTP service: inactive"; the sssd log repeats "Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Clock skew too great". From the Linux build notes, last edited in 2023: "chronyd disabled — the hypervisor keeps guest time". From cluster B's host settings: the time source is 10.1.0.5, an address retired last year, and the hosts' clocks were set by hand when they were installed in June. Two lines for the candidate to use: the nine Windows servers on cluster B are within a second of DC01, and the two Linux servers still on cluster A are fine. The red herrings: an SRV lookup for the domain's LDAP service returns both domain controllers, which is correct; and last Tuesday's patching updated the sssd packages on every Linux server, including the two that still work. At the bottom, a colleague's note: "rejoin them all to the domain?"
Fourteen servers stopped accepting domain logins over the weekend. Here is what the on-call admin collected. What is wrong, what do you do first, and what do you refuse to do?
What this question is for, and what to listen for
Purpose
Reads troubleshooting on Linux against a directory. Everything needed is on the sheet; the separator is whether the candidate uses the servers that still work to eliminate causes, rather than trying fixes in turn.
Signals to score
- Reads "local account works, domain account fails" as a fault in the authentication path, not in SSH or the servers
- Puts the seven-and-a-half-minute offset beside the five-minute Kerberos tolerance and connects it to the sssd error
- Uses the two unmoved Linux servers to rule out the sssd update, and the move to cluster B to date the fault
- Explains why the Windows servers on the same hosts were unaffected, from the evidence on the sheet
- Enables time synchronisation on the Linux guests against the domain controllers or another proper source, and stops the hypervisor setting their clocks
- Restarts sssd once the clock is right and proves the fix with a fresh domain login
- Refuses to rejoin the servers to the domain and says what rejoining would cost and fail to fix
- Fixes the hosts' own time source, because every guest placed on cluster B later inherits the problem
- Says what a sudden seven-minute clock step can disturb — scheduled jobs, log timelines, anything that compares timestamps — and checks it
- Corrects the build note so the next server is not built the same way
Follow-up questions
- A local account works and a domain account does not. What have you just ruled out?
- Two Linux servers were not moved and had the same sssd update. What does that tell you?
- Your colleague wants to rejoin all fourteen to the domain. Why not?
- The clock is right now and logins still fail on one server. What next?
- Why did nobody notice on the Windows servers?
The caller who lost her phone
What this part is for
Purpose
The third sheet is a service desk escalation. Thursday 17:48, after the finance office has gone home: a caller says she is Maria Keller, the finance director, that her phone was stolen at the airport, and that she needs her multi-factor authentication reset now because a supplier payment must be approved before 19:00. She is calling from a mobile number ending 0925; the number in her directory record ends 4471. She answered the three questions the service desk procedure asks — employee ID, manager's name, start date — and the analyst has written "verified 3/3". The procedure, last revised in 2024, says that two correct answers are enough to remove a user's registered methods so they can register new ones. Also on the sheet, from the cloud directory's sign-in log for her account: 17:21 and 17:23, correct password, sign-in stopped at the MFA prompt because the push was denied, from an address in a country she has no travel booked to; 17:31, correct password, push not answered. Her calendar shows her in the office until 17:30 today and on leave from Friday. One line from finance: supplier payments over the approval limit also need a second approver. The misleading line is "verified 3/3". The deliberately correct thing is that the analyst has not reset anything yet and escalated instead.
The service desk has escalated this call to you at 17:52, and the caller is still holding. What do you do in the next ten minutes, and what changes in the procedure next week?
What this question is for, and what to listen for
Purpose
Reads identity and access at the point where a directory is most often broken into: a person persuading the service desk. The separator is whether the candidate acts on the sign-in log rather than on the caller's story.
Signals to score
- Does not remove or add any authentication method while the caller is on the line
- Says the three answers prove little, because a manager's name and a start date are public and an employee ID is not a secret
- Reads the sign-ins before the call as someone already holding her password, whoever the caller turns out to be
- Verifies through a channel the caller does not control — the number on file, her manager, or someone who can see her
- Resets the password and revokes the account's existing sessions now, and accepts that the real Maria may be locked out until she is verified
- Checks what the account has already done or had changed: recently registered methods, mailbox rules, sign-ins that succeeded
- Warns whoever approves payments that a request from her tonight is not to be acted on until verified
- Records the call and hands it to whoever deals with security incidents, as an attempt rather than a service request
- Replaces question-based verification for authentication resets with a call-back to a number on file or a sponsor who knows the person
- Gives a genuine traveller a way back in the same evening, such as a short-lived one-time code issued only after verification
Follow-up questions
- She answered all three questions. Why is that not enough?
- What do the sign-ins at 17:21 and 17:31 tell you, whoever is holding?
- The caller says the payment will fail at 19:00 and it will be your fault. What do you say?
- Suppose it really is her. How does she get back in tonight?
- What does the procedure say by next Friday?
Thursday, 15:40
What this part is for
Purpose
The fourth sheet is an advisory and the context around it. The vendor of the managed file transfer software on `MFT01` — the server finance uses to exchange payment files with the bank and with suppliers — published at 15:40 today: critical, remote code execution without authentication through the web interface, exploited against customers for at least a week before publication; a fixed version is out; the interim mitigation is to block access to the web interface, and SFTP is not affected. Do not invent a real vulnerability identifier; the product is left unnamed on purpose. The asset record: `MFT01` is a Windows VM reachable from the internet on 443 for partner uploads and on 22 for SFTP, runs an affected version, was last patched in April, and belongs to finance operations. The change calendar: the month-end freeze runs from Friday 00:00 to Tuesday 08:00; the change board meets on Tuesday at 10:00; the change policy allows an emergency change with the approval of the IT manager and the system's owner. The month-end payment run on Monday depends on `MFT01`. The advisory lists what to look for if the server has been attacked: unexpected files in the web application's folder and administrator accounts in the application that nobody created. The red herring: Monday's scheduled vulnerability scan reported no critical findings on `MFT01`, which predates the advisory and so says nothing. The deliberately correct thing: last night's backup of `MFT01` completed and was checked.
It is 15:40 on Thursday, the freeze starts at midnight, and finance's month-end runs through this server. Take me from now to Monday morning: what you do, in what order, and who has to say yes.
What this question is for, and what to listen for
Purpose
Reads patching and change control when the process and the risk point in different directions. Most candidates can argue for patching now or for waiting; the separator is whether they treat a week of exploitation as a possible compromise and use the emergency route the policy already provides.
Signals to score
- Confirms exposure from the server itself — the installed version and the web interface's reachability from outside — rather than from the scan
- Sets aside Monday's clean scan because it predates the advisory
- Treats a week of exploitation as meaning the server may already be compromised, and checks the advisory's indicators before patching as well as after
- Uses the emergency change route today, naming the IT manager and finance operations as the approvers, instead of waiting for Tuesday or ignoring the freeze
- Applies the interim mitigation within the hour if the patch cannot go in tonight, and agrees with finance that partners switch to SFTP meanwhile
- Takes a fresh backup or snapshot immediately before patching, and knows it is a rollback for the patch, not a recovery from a compromise
- Patches before midnight, or states the time by which it will be done and why the mitigation holds until then
- Verifies afterwards with the version, a real partner upload and a second check of the indicators
- Changes course if an indicator is found: isolate the server, preserve evidence, bring in whoever handles security incidents, and do not simply rebuild it
- Asks why an internet-facing server was five months behind, and proposes a separate, faster patch rule for exposed systems
Follow-up questions
- The scan on Monday says `MFT01` has no critical findings. Does that change anything?
- The vendor says exploitation started a week ago. What does patching today not undo?
- The freeze starts at midnight. Who can approve this, and what do you tell them in two sentences?
- Blocking the web interface stops partner uploads. How do you decide whether that is acceptable?
- You find a file in the web application's folder that nobody recognises. What changes?
Closing
That was the fourth. The rest of the time is yours: ask me about how this team actually runs — how changes get approved, when we last restored something for real, what the service desk may do without us.
What this line is for
Purpose
Scores nothing and goes in the notes. Someone who has run a small estate tends to ask about change approval, restores and access rather than about which products we buy.
Before you go, one true thing about us: [name one real gap on your own estate — a restore nobody has tested, a procedure the service desk works around, a server that is months behind]. If you join, it is yours to help fix, and I would rather you heard it from me.
What this line is for
Purpose
Ends on a specific, checkable fact about the team. It is the honest pitch to the candidate this round is looking for, and it only works if it is still true on the day, so check before you say it.
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 Scenario-based Questions round for a System Administrator role. It gives you a 60 min script to follow in the conversation — 4 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 Scenario-based Questions round assess?
- This round is focused on: Sysadmin scenario questions with the evidence attached: a group change that did not take effect, domain logins failing on Linux, a caller asking for an MFA reset, an actively exploited vulnerability on a server finance depends on — whether the candidate reads what is on the page before acting, and knows which quick fix makes things worse. It works through Added to the group, still denied, Domain logins fail on the Linux servers, The caller who lost her phone and Thursday, 15:40, scoring against 40 observable signals, with follow-up prompts on all 4 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- 60 min on 4 questions. The questions take in Added to the group, still denied (15 min), Domain logins fail on the Linux servers (15 min), The caller who lost her phone (13 min) and Thursday, 15:40 (17 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:
Hiring for this role?
Open this plan in Hirezen and make it a position in one click.
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
Free for your first open role.