Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.
Platform, DevOps and site reliability · Mid level
How to assess a Systems Administrator
The systems administrator screen fails by testing a checklist for a job that is now a migration. BLS has this occupation shrinking 4 percent through 2035 while still generating around 13,400 openings a year, which describes an occupation being re-titled rather than eliminated: the estates still exist, the pager still rings, and the person hired into it is expected to keep a decade-old environment alive while gradually moving it toward code. A certification checklist screens for the maintenance half and is silent on the migration half. It is also silent on the two behaviours that produce almost all of the damage in this role. The first is change discipline in an environment with no staging: there is one file server, it is in use, and the decision about whether to change it now or at 11pm on Saturday is made by one person with no review. The second is proven recovery — the difference between having backups and having restored from them, which is a distinction that only becomes visible on the worst day of the year. Neither is a knowledge question, so neither is on the test.
The systems administrator is the role in this hub with the clearest statistical identity and the murkiest job description. BLS counts 323,600 of them in the US in 2025, projects the number down 4 percent by 2035, and still expects around 13,400 openings a year — a picture of steady replacement hiring into an occupation whose centre of gravity is moving. The person you hire will spend part of their week maintaining an environment that predates them and part of it converting that environment into something a platform team could eventually own. Both halves matter and they select for slightly different people, which is the central difficulty in hiring here.
The maintenance half is defined by an absence: there is usually no test environment. A backend engineer proposes a change and it is reviewed, tested in staging, deployed behind a flag and rolled back if wrong. A systems administrator changes the thing that is in use, at a time they chose, on their own judgment, and the rollback plan is whatever they thought of beforehand. That makes change discipline the single most valuable trait in the role, and it is almost entirely a matter of habit: taking the backup first, writing down what was changed, testing the restore path, choosing the maintenance window even when it is personally inconvenient. Uptime Institute's 2026 analysis reports failure to follow established procedures as still the leading driver of human-error outages, with 57 percent of surveyed operators saying their last major outage cost more than $100,000. This is the role where that finding is most directly a description of daily practice.
The second defining feature is diagnosis without documentation. A strong systems administrator can be dropped into an estate they have never seen and, within an hour, tell you what is running, what depends on what, and which of it nobody understands any more. They do that by reading the system rather than asking for a diagram that does not exist — processes, units, cron entries, firewall rules, what is listening on what, when packages were last updated. That is a genuinely observable skill in a monitored sandbox and it is the closest thing this role has to a core aptitude test.
The third is communication with people who are not technical, which is more central here than anywhere else in the hub. Systems administrators sit adjacent to the whole organisation and are routinely the person explaining why the shared drive is slow, why the change has to happen on Saturday, or why the request cannot be done the way it was asked. Doing that without condescension and without over-promising is a large part of whether the role is judged successful.
The migration half is where the hiring risk of the future sits. The DORA finding that 90 percent of surveyed organisations now run at least one internal platform is the environment this role is being pulled into. The question for a hiring manager is not whether the candidate already writes configuration management code — many good ones do not yet — but whether they are curious about it or threatened by it. The administrator who has automated the three things they do most often, badly, in a shell script, is a better bet than one who has memorised more command flags.
The assessment therefore leads with diagnosis rather than construction. The sandbox is a small, undocumented, slightly broken estate: a service that will not start after a reboot, a disk filling for a non-obvious reason, a scheduled job that has been silently failing. The candidate investigates, fixes what they can, and writes the handover note. Then the conversation: what did you change, and how would I undo it? You restarted this service — what did you check first, and what would you have checked if it had not worked? Are the backups here restorable, and how do you know? Explain to the finance manager, who is not technical, why this needs an outage on Saturday. That last question is the one most systems administrator interviews never ask, and it is the one their colleagues care about most.
What the job actually needs
- diagnosing an estate nobody documented
- change discipline on systems with no test environment
- backup and restore that has actually been proven
- explaining a technical constraint to a non-technical colleague
- migrating toward automation without breaking what exists
How people fail in this seat
- makes an undocumented change that nobody can reverse
- has backups that have never been restored
- patches during business hours because the maintenance window was inconvenient
- holds critical knowledge only in their own head
- resists automation because it threatens the way things are done
What most employers do instead
CV screen for certifications and named platforms, a trivia interview on command syntax and operating system internals, and a reference check.
The assessment
About 68 minutes end to end.
The systems it runs in
SSH access to a small Debian or Ubuntu estate with no diagram and nobody to ask: services under systemd with their logs in journald, a scheduled job under cron whose output goes nowhere because nothing was ever configured to receive it, and a nightly backup whose exclude list quietly covers the application's data directory. The disk fault is the POSIX one — a large file deleted while a process still holds the descriptor — so the free-space and directory-usage views disagree, and closing that gap requires lsof or the process's own file descriptors rather than deleting more files. The reboot in t2 is the only complete proof that the unit is enabled rather than merely running.
- Debian
- Ubuntu
- systemd
- systemctl
- journalctl
- cron
- lsof
- df
- du
- SSH
- restic
RHEL, Rocky or Alma for buyers in the Red Hat family, where dnf and SELinux change the commands and leave the faults intact. A Windows Server estate is a separate fixture rather than a translation of this one, and that is worth stating plainly rather than papering over: the deleted-open-file fault has no Windows equivalent, and the service, scheduling and backup models differ enough that a translated fixture would test neither estate honestly. Buyers running Windows should ask for the Windows fixture and not this one.
What the candidate actually does
| Task | What happens |
|---|---|
| An estate nobody documented coding_sandbox · 20 min | SSH access to a small Debian estate the candidate has never seen, with no diagram, no runbook and nobody to ask. Three things are wrong and there is not time to fix all three. A service under systemd does not come back after a reboot, because the unit runs but was never enabled. A disk is filling, and the reason is non-obvious — a large log file was deleted while a process still held the descriptor open, so the free-space and directory-usage views disagree with each other. And a cron job has been failing silently for weeks because its output goes nowhere. The candidate is asked, at the twenty-minute mark, to say what is running here, what depends on what, and which of the three they would fix first. The fork. On the disk, deleting more files is the reflex and does nothing, because the space is held by a running process rather than by a directory entry; the free-space figure does not move and a careless candidate reports it as fixed. Finding the process holding the deleted file, with lsof or its own file descriptors, requires knowing that df and du can disagree and asking why. |
| A change with no staging behind it coding_sandbox · 10 min | The candidate fixes the service that does not survive a reboot. It is 11am, the estate is in use, there is no test environment, and the only complete proof that the fix works is a reboot. The fork. Rebooting to verify is the honest test and takes the estate down in the middle of the working day for everyone who depends on it. Capturing the original configuration first, verifying everything verifiable without a restart, and proposing the reboot into a window is slower, less conclusive, and correct. |
| Are the backups restorable coding_sandbox · 12 min | A nightly backup job exists, has run every night for a year, and reports success every time. The candidate is asked whether the estate is recoverable. The job's exclude list quietly covers the directory holding the application's data, and the archive it produces is therefore complete, healthy and useless. The fork. Reading the job's log and reporting that backups are healthy takes two minutes, matches every piece of available evidence and is wrong. Restoring one archive into a scratch location and looking for the data that matters takes ten and is the only method that finds it. |
| The finance manager and the Saturday outage live_call · 8 min | A live call with an AI finance manager who is not technical, who has month-end close approaching, and who wants to know why the reboot cannot happen at lunchtime on a weekday like it did last time. She is polite, persistent, and does not accept jargon. The fork. Reaching for technical vocabulary ends the conversation without transferring understanding, and simply agreeing to the weekday window to avoid friction moves the risk onto the business without telling anyone. Explaining the actual consequence in her terms, offering the two real options with what each costs, and letting her choose is the version that works. |
| The handover note written_artifact · 8 min | The candidate writes what the next administrator, or their own future self at 3am, needs — what was changed, where the original is, how to undo it, what is still broken, and what they never worked out. The fork. A list of commands run is a record and not a handover. A note that names the reversal path for each change, and admits the thing that was never understood, is what makes the estate survivable by someone else. |
| Undo it from your own note live_call · 10 min | A conversation about the candidate's own session. You restarted this service — what did you check first, and what would you have checked if it had not come back? The disk showed space free that the directory listing did not account for; when did you notice, and what did that tell you? How do you know the backups are restorable? Walk me through undoing your change using only your own note. |
The mark scheme
Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.
Reads the system rather than asking for a map that does not existweight 0.2Within the window can say what runs, what depends on what, what is scheduled, and which of the three faults threatens the business soonest, with the e…
Change discipline where there is no second chanceweight 0.25Copies the original before touching it, states which parts of the fix are verified and which cannot be verified without a restart, and proposes the re…
Proves recovery instead of trusting the statusweight 0.2Restores into a scratch location, checks specifically for the data the business would need, names the gap, and states the general principle that an un…
Explains a technical constraint to someone without technical vocabularyweight 0.2States the consequence in the counterpart's own terms, offers the two genuine options with what each costs and who bears the risk, holds the technical…
Leaves the estate more legible than it was foundweight 0.15A stranger could undo every change from the note alone, the unfixed faults are named with what is known about each, and at least one thing the candida…
How it is scored
Weighted mean of the five criteria, each scored 1 to 5 against the anchors, reported with the excerpt that earned it. One procedural check is reported as a pass or fail alongside the scores rather than inside them — in the session review the candidate is asked to reverse their own change using only their own handover note, and whether the note was sufficient is a binary observation that a hiring manager should see directly.
Integrity
- monitored sandbox in which AI assistance is available and its use is part of the recorded session rather than a breach
- the estate's faults are instance-specific and undocumented, so a general answer about disk space or service units does not resolve them
- the disk fault in particular has a plausible wrong fix that appears to work, so a correct-sounding response is separable from a correct one by the state of the system afterwards
- the review asks the candidate to execute a reversal from their own note, which is a test of the artefact rather than of recall
- no claim is made that undisclosed assistance is detected; reviewers score the system state, the recording and the conversation, and are instructed not to infer authorship from command fluency
The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.
What you receive
- full shell transcript with timestamps
- system state before and after, including free space, service status and the contents of the restored archive
- the handover note
- recording and transcript of the finance call and the session review
- pass or fail on reversing the change from the candidate's own note
- per-criterion score with the excerpt that earned it
Who decides
Recommended, with one specific instruction. The reviewer reads the handover note before anything else and attempts, on paper, to reverse the changes from it alone; that judgement is recorded before they see the scores, because it is the criterion most likely to be scored generously by a reviewer who already knows what the candidate did. Reviewers confirm or override each criterion in writing. The override to expect is a candidate who did reboot during the day and was right to — a single-user estate, a service already down, an explicit statement that the impact was nil. The rubric cannot see that context and a human can.
What this does not measure
This design measures an hour of careful work by someone who knows they are being observed, and the role's real failure mode is a habit that erodes over years when nobody is. It does not observe on-call temperament sustained across months, and it does not observe behaviour during a genuine multi-hour outage with the business stopped and a director in the room — the situation in which change discipline actually breaks down. It also cannot see the most damaging pattern in this role, which is the administrator who holds critical knowledge only in their own head; that becomes visible over a year of handovers and holidays, and a session that explicitly asks for a handover note prompts the behaviour it is measuring. Read the note criterion as evidence the candidate can write one, not that they will. Three narrower cautions. The estate must be presented in the operating system family the candidate declared; scoring diagnosis while someone translates between Linux and Windows conventions measures the translation and disadvantages administrators whose experience is concentrated in one. The finance call must be scored strictly on whether understanding was transferred and options were offered, never on accent, register, idiom or how assertive the candidate sounds — reviewers get the transcript alongside the recording specifically so that fluency does not leak into the score, and a candidate whose plain language is unpolished but effective must outrank one who is smooth and left the counterpart uninformed. And the timings are a filter; extended time should be available on request, applied before the session and not surfaced to the reviewer, since every scored variable here concerns care and method rather than speed. Monitor outcomes by declared platform and by requested adjustment.
The systems administrator design leads with reconnaissance rather than construction, because that is the actual first hour of the actual job. Nobody hands this person a clean environment and a specification. They are handed an estate that predates them, built by someone who left, documented in a wiki page last edited four years ago, and they are expected to keep it alive while gradually converting it into something a platform team could own. The assessment therefore begins with the only question that matters on day one: can you work out what this is, without asking anyone, in twenty minutes?
The disk fault is the sharpest instrument in the set and it is worth explaining why. Space held by a deleted-but-open file is not an exotic puzzle; it is one of the most common ways a Linux estate runs out of room, and it has the useful property that the naive fix produces no error. The candidate deletes more files, the free-space figure does not move, and there is a genuine fork in what happens next. One kind of administrator reports the disk as cleaned and moves on, having seen no failure. Another notices that the number did not change and treats that as information. The second behaviour is the entire competence, and it cannot be faked, prepared for, or answered from general knowledge — the discrepancy exists only in this instance of this sandbox.
The backup task carries the same shape at higher stakes and is the piece this design would keep if it could keep only one. Every signal available to the candidate says the backups are fine: the job runs, the log is green, the archive exists and is not corrupt. The only method that finds the truth is restoring one and looking inside for the data the business would actually need. That is the difference between having backups and having recovered from them, and it is a distinction that becomes visible in most organisations exactly once, on the worst day. Scoring it requires no cleverness on the reviewer's part: either the candidate opened the archive and found the omission, or they did not.
The finance call is the component that most systems administrator interviews never include, and its absence explains a large share of why these hires are judged unsuccessful by people outside the technical team. This role sits adjacent to the whole organisation. Its occupant is routinely the person explaining why the shared drive is slow, why the change must happen on a Saturday, and why the request cannot be done in the way it was asked. The two failure modes are symmetrical — the administrator who retreats into jargon and the one who agrees to the unsafe window rather than have the argument — and both are expensive. The counterpart is written to be reasonable and immovable so that neither escape is comfortable.
The handover note, and the review question that makes the candidate reverse their own change from it, close the design on the thing this family's evidence keeps pointing at: procedures fail to be followed largely because the procedures are bad, written by the person who already knew, at a level of detail that assumes the reader does. Asking a candidate to execute their own note is a direct measurement of that, and it is scored as a binary and reported separately because it does not deserve to be averaged into anything.
What this design deliberately refuses is the certification checklist. Nothing here asks for command syntax, and a candidate who reaches for documentation mid-session is not penalised, because looking things up is what the job consists of. The scored variables are what they checked, in what order, what they copied before changing, what they proved rather than assumed, and what they wrote down for whoever comes next.
Sources
Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.
- US Bureau of Labor Statistics, Occupational Outlook Handbook, Network and Computer Systems Administrators, 2025, https://www.bls.gov/ooh/computer-and-information-technology/network-and-computer-systems-administrators.htm
- Uptime Institute, Annual Outage Analysis 2026, press release, survey of data centre and IT operators, https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2026
- Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, 24 September 2025, vendor-run survey of nearly 5,000 technology professionals worldwide, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.
Read a sample reportOr talk to us about this role