System administrator: job description, interview questions, and screening workflow

The generic advice for this role is "look for AWS or Azure certifications and years of Linux experience." That advice tells you almost nothing about the one thing that actually matters: whether you can hand this person the keys. A system administrator isn't the person fielding a confused coworker's password reset or a frozen laptop, that's a different hire, covered in our IT help desk technician hiring guide. Sometimes one small company needs both jobs done by the same person. Sometimes they split into two hires as the company grows: a help desk technician for front-line user support, and a system administrator for the backend infrastructure nobody outside IT ever sees. A system administrator holds root or admin access to your servers, your cloud accounts, your network, and every login in the company, often with no senior engineer looking over their shoulder to catch a bad call. The real failure mode isn't a missing certification. It's finding out, after something breaks at 2am with no one else to call, that this person never actually tested a backup restore, never hardened a server past its factory defaults, or freezes instead of working the problem methodically. This guide is built to screen for that judgment, because a resume full of acronyms can't show it, and it's exactly what decides whether this hire protects your company or becomes its biggest single point of risk.

What a system administrator actually does at a small company

At a large company, infrastructure is a team: someone owns networking, someone owns cloud cost and architecture, someone owns security, and a system administrator handles one slice of it with peers to check their work. At a small tech or software company, usually one person owns all of it, often as the most senior technical hire outside engineering, or the only technical hire, period. There's no one to catch a bad configuration before it ships, and no one to ask when a decision is genuinely hard.

The core responsibilities, in practice:

• Administering and maintaining servers, whether on-prem, in a data center, or in the cloud
• Configuring and monitoring the network: firewalls, VPNs, routing, and uptime
• Managing backups and disaster recovery, including actually testing that a restore works
• Provisioning and de-provisioning user accounts and permissions at the infrastructure level, not just a coworker's laptop password
• Patching and hardening systems against known vulnerabilities across the whole environment
• Owning the relationship with cloud providers (AWS, Azure, Google Cloud) and other infrastructure vendors
• Managing domain registration and DNS, where one careless change can take down email or the company's whole website
• Being the person on call when something breaks, and knowing when a problem is big enough to escalate to a vendor's support line

None of that is front-line troubleshooting. A confused coworker who can't connect to wifi is a help desk problem. A production database that won't come back up after a failed patch, at a time when nobody senior is awake to help, is a system administrator problem. The technical bar here is real, but it's not really what separates a good hire from a bad one. What separates them is judgment under a very specific kind of pressure: no backup, no second opinion, and access to systems that can genuinely hurt the business if handled carelessly.

Job description you can post today

Copy this, then adjust the specifics (your infrastructure stack, your cloud provider, your hours) to match your company.

System administrator
[Company name] is looking for a system administrator to own and maintain the infrastructure our team runs on. You'll manage our servers, network, and cloud environment, keep our systems patched and secure, and be the person who makes sure things stay up and recoverable when something goes wrong.

What you'll do
Administer and monitor our servers and network, on-prem and in the cloud. Manage backups and disaster recovery, and actually test that restores work. Provision and de-provision user accounts and permissions as people join and leave the company. Apply security patches and harden systems against known vulnerabilities. Own our relationship with our cloud provider and other infrastructure vendors. Manage domain and DNS records. Be the point of escalation when something breaks, including outside normal hours for genuine emergencies.

What we're looking for
Hands-on experience administering servers and cloud infrastructure (AWS, Azure, or Google Cloud), not just certifications naming them. A real, demonstrated backup and disaster recovery practice, including restore testing. Sound judgment about security hardening and access control, since you'll often be the only technical check on infrastructure decisions. Comfort being the point of accountability when something breaks and there's no one senior to ask.

Schedule
[Insert hours, e.g. Monday-Friday, 9am-5pm, with on-call availability for infrastructure emergencies]

[Insert pay range, per your company's policy and any applicable state salary transparency requirements]

10 interview questions, and what a good answer sounds like

1. Walk me through how you'd set up backups for our production systems, and how would you actually verify they work?

This is the single most revealing question you can ask a system administrator candidate. A strong answer names a real backup strategy (something like the 3-2-1 rule: three copies, two different media, one offsite or immutable) and, critically, describes a process for testing restores on a schedule, not just confirming the backup job ran. A candidate who says "we run nightly backups" and stops there, with no restore testing, is describing a backup plan nobody has actually verified works.

2. Tell me about a time you hardened a new server before putting it into production. What did you actually do?

You want a concrete sequence, not a vague reference to "security best practices." Listen for specifics: disabling default accounts and unused services, applying least-privilege permissions, configuring the firewall, setting up logging and monitoring before the server goes live. A candidate who says "I installed antivirus and moved on" is describing the bare minimum, not hardening.

3. Walk me through your patch management process. How do you balance staying current on security patches against the risk of breaking something in production?

Good answers describe a staged process: testing patches in a non-production environment or on a small group of systems first, scheduled maintenance windows, and a rollback plan if something breaks. They also prioritize by severity, moving faster on a critical security patch than a minor feature update. A candidate who says they patch "whenever I get to it," with no test step and no plan if something goes wrong, is describing a habit that eventually takes down something important.

4. Tell me about your process for provisioning and de-provisioning accounts and permissions when someone joins or leaves the company.

This tests access-control discipline, one of the highest-stakes parts of the job. A strong answer describes granting access based on role and need, tied to a clear trigger from HR or a manager, with immediate revocation the day someone leaves, not "whenever I get around to it." A candidate who grants broad admin access by default, or who can't describe a process for removing access promptly, is a real risk: stale accounts and over-broad permissions are exactly how a departed employee, or an attacker who compromises their old login, does damage.

5. You get paged at 2am because a critical system is down and there's no one else awake to help. Walk me through what you actually do.

At a small company, this is the job, not an edge case. Listen for a systematic process: checking monitoring and logs first to understand what actually broke, working through a defined set of diagnostic steps before guessing, and knowing when the problem is beyond them and it's time to escalate to a vendor's support line rather than making things worse. A candidate who describes panicking, guessing at fixes, or has no sense of when to escalate is describing exactly the scenario that turns a bad night into a multi-day outage.

6. How do you decide what to run and manage in-house versus what to hand off to a cloud provider or an outside vendor?

This surfaces real infrastructure judgment versus someone who either does everything themselves out of habit or defers everything to a vendor without understanding what they're paying for. A strong answer weighs cost, complexity, and risk, and can name a real example of a decision they made either way and why. A candidate with no clear reasoning here, just "it depends," without being able to say what it depends on, hasn't actually had to make this call before.

7. Walk me through how you'd manage our domain and DNS records, and what could go wrong if it's handled carelessly.

DNS is a small, unglamorous piece of infrastructure that can take down email, the website, or both if a candidate doesn't respect it. A strong answer mentions documenting records, using registrar-level protections like a transfer lock, understanding propagation and TTL, and naming the real consequences of a mistake, since a wrong record can silently break email delivery for hours before anyone notices. A candidate who treats this as trivial, or can't describe what a bad change actually breaks, hasn't been burned by DNS yet, which at a company with no backup IT person is a bad way to learn.

8. Tell me about a real security incident or a close call you've dealt with. What happened, and what did you do?

You want a real story, not a hypothetical. Listen for how they noticed the problem, what they did to contain it, whether they communicated with the right people, and what they changed afterward so it couldn't happen the same way twice. A candidate who can't produce a real example, or who describes a serious incident casually, with no follow-up fix, is a flag. Security incidents happen to everyone eventually; what matters is how someone handles one.

9. How do you document our infrastructure so you're not the only person who understands how it all fits together?

This matters more at a small company than it sounds, because there's no team to absorb the knowledge if this person leaves or is unreachable during an emergency. Good answers mention runbooks, network diagrams, and a shared, secured system for credentials, like a password manager or secrets vault, not a personal notes file. A candidate who says it's "all in my head" is describing a single point of failure, not a system.

10. Why are you interested in being the sole or lead system administrator at a small company, with no senior engineer to double-check your infrastructure decisions?

This surfaces whether they understand what they're signing up for. A strong answer names something real: ownership over the whole environment instead of one narrow slice, the range of problems they'll get to solve, direct visibility into how the business actually runs. A candidate who can't articulate a reason beyond "it's a good line for my resume" may not be prepared for the isolation and accountability this role actually carries.

A scorecard you can score candidates against

Ten questions are only useful if everyone on your side is listening for the same thing. Score every candidate on the same six signals, so you're comparing evidence instead of comparing gut feelings from different conversations. Copy this into a doc and fill in a row per candidate.

How to screen system administrator candidates without losing a week to it

Truffle is a candidate screening platform that combines one-way video interviews, talent assessments, and resume screening, so you can build a screening workflow around what actually matters for a role that hands one person a huge amount of trust, with almost no in-house technical backup to double-check them.

Tech and software roles have seen applicant volume climb well past what a small company can read resume by resume, even for infrastructure roles with a real technical bar, since a market downturn and easy-apply tooling flood every posting with resumes that all claim the same certifications and cloud platforms. On top of the volume, there's a growing problem of candidates who aren't who they say they are on a live call: proxy interviewees, or someone running an AI overlay during a video interview and feeding them answers in real time. A live panel interview is the easiest format to game this way, since there's a screen and a moment-to-moment feed for an overlay to work against. A one-way interview, where a candidate responds to your specific prompts on their own time and you review the recording afterward, is a harder setup to run that kind of live coaching against, though it's worth being honest that no single step makes a process impossible to game. The point isn't a single unbeatable filter. It's stacking a few signals that are each harder to fake than the last.

A workflow that fits a small tech or software company handing over real infrastructure trust:

• Resume screening first. Cut the obvious mismatches on cloud platforms, years of hands-on infrastructure experience, and the specific stack you actually run, before you spend time on anyone. Certifications are useful signal here, but only as one input, not the whole read.
• A short one-way video interview, not a live panel round, for your first real look. Ask 2-3 of the scenario questions above, like the backup verification question or the 2am incident question, so you can hear how someone actually reasons through infrastructure judgment under pressure, before you commit any live interview time.
• A short, practical skills check as a baseline gate, not a substitute for a technical interview. Truffle doesn't have a dedicated infrastructure or systems administration assessment yet, so our computer literacy examination is the honest starting point: it screens out someone who can't clear basic digital hygiene and access-control judgment before you invest live interview time on deeper infrastructure questions. It does not test server configuration, backup architecture, or security hardening. That judgment still has to be tested live.
• A real, live technical conversation for the candidates who clear the first three steps. This is where you go deep on the questions above: backups, hardening, incident response, and the specific systems your company actually runs. By the time you're on that call, you already know they can communicate clearly and clear a basic skills bar. The live conversation is for the infrastructure judgment a resume and a one-way interview can't fully test.

Our resume screening and one-way video interview tools handle the first two steps in one place, with AI that surfaces your strongest matches against the criteria you set. You review the evidence and decide. It doesn't pick for you.

3 questions from the skills check we'd actually run for this role

A skills check only helps if you're honest about what it does and doesn't cover. Truffle doesn't have a dedicated infrastructure or systems administration assessment yet, so these three questions are pulled from Truffle's computer literacy examination, a baseline computer-literacy gate, not a substitute for testing real server, network, and security judgment live. What it's good for: screening out someone who can't clear basic digital hygiene and access-control instinct before you invest any live interview time on the deeper infrastructure questions above. Try them yourself before you decide what "job-ready" means for your opening.

The point isn't these three questions. It's that a baseline digital-hygiene check like this tells you, in a few minutes, whether someone clears the floor before you spend real interview time on the infrastructure judgment that actually decides this hire: backups, hardening, access control, and what happens when something breaks with no one else around. Truffle's AI scores and surfaces the results against the bar you set. You still make the call on who clears it, and who's worth a real technical conversation about your infrastructure.

Common hiring mistakes for this role

Over-indexing on certifications instead of testing real infrastructure judgment. An AWS or Azure certification shows someone studied the material and passed an exam. It doesn't tell you whether they actually test their backups, or whether they'll panic or work the problem when something breaks at 2am. Weight the scenario questions above over a line item on a resume.

Not asking specifically about access control and least privilege. "Admin experience" on a resume says nothing about whether someone defaults to broad, convenient access or narrow, deliberate access. This is one of the highest-stakes parts of the job and one of the easiest to skip in an interview if you don't ask about it directly.

Hiring someone who becomes a single point of failure. If nothing is documented, a runbook doesn't exist, and credentials live in one person's head, your infrastructure is only as available as that one person is. Probe directly for how a candidate documents and hands off knowledge, not just how they solve problems solo.

Underestimating what "no one to call" actually means. A candidate who's only ever worked on a team with senior engineers or a managed service provider to lean on may struggle when they're the last line of defense and a vendor support ticket is the only backup. Probe directly for a real story of handling a hard problem completely alone.

Trusting a smooth technical interview without verifying it's the real candidate. Proxy interviewees and AI-assisted live answers are a growing problem in tech hiring, and a polished live call isn't proof of anything on its own, especially for a role with this much access to verify carefully. Combine a resume screen, a one-way interview where the candidate responds on their own time, and a skills check, so you're triangulating more than one signal instead of betting the hire on a single conversation.