Questions to Ask in a System Administrator Interview
A system administrator interview is your one chance to find out what you would be handed the keys to, and these are the questions to ask in it. They run in the order the job would reach you: the environment itself, then patching, backups and monitoring, how changes get approved, on-call and after-hours work, and the daily job of tickets, team and budget. A final group turns the table for a manager hiring a sysadmin, and every question comes with a note on the answers to hope for and the ones to worry about.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Environment
What does the environment look like today: how many servers, which operating systems, and how much is on-premises versus in the cloud?
Why ask it
A closet of twenty Windows servers and a fleet of two thousand Linux instances have little in common beyond the job title, so get the size before anything else. A manager who gives rough numbers without hunting for them probably has an inventory. If nobody can say how many servers there are, expect your first months to go to counting them.
What would I be responsible for on day one, and what belongs to the network, security or help desk teams?
Why ask it
Depending on the company, the title can mean resetting passwords or running a data center. Listen for where the lines fall on networking, phones, printers and laptops. 'A bit of everything' is an honest answer at a small company, so ask what a bit of everything came to last week.
What is broken or behind right now that you would want me to have dealt with in my first 90 days?
Why ask it
Whatever comes first is usually what hurts most, such as a stalled migration or a backup job that keeps failing. If the list runs long, ask which one they would pick if only one got done. That one is the real job.
Who looked after these systems before me, and are they still around to ask?
Why ask it
You learn why the job is open and what kind of handover to expect. A predecessor who moved up inside the company is the best case. If they have left the company, find out what stayed: runbooks, a password vault, or only a contractor's phone number.
What is the oldest system still in production, and what is the plan for it?
Why ask it
Nearly every environment has one: an operating system past the end of its support, or a box nobody dares restart. Ask what still depends on it and whether it could be restored onto new hardware if it died. A retirement date is the reassuring part, and a laugh with no date means the day it fails would be yours.
Which systems can the business not work without, and how long can each one be down?
Why ask it
The reply you want ranks them and puts hours against each, agreed with the people who use them. If everything is critical, nothing has been ranked, and you would be the one choosing what to bring back first in the middle of the night.
What runs the virtual machines or containers here, and is a move to another platform being talked about?
Why ask it
The platform underneath decides which skills you would use every day. Moving from one to another is among the bigger projects an admin can be handed, so if it is under discussion, find out how far along it is and who is doing the planning.
Which cloud providers and accounts are in use, and who is able to create resources in them?
Why ask it
One set of accounts with someone watching the bill is the tidy version. Several teams with their own accounts on company cards means inheriting things nobody remembers starting. Ask who sees the invoice each month and whether anyone has ever questioned it.
How are user accounts and access managed: one directory with single sign-on, or a separate login for each system?
Why ask it
With one directory, someone who leaves is switched off once. Ask how many systems still keep logins of their own, because each is a place where an old account or a forgotten service account can outlive its owner. If the answer is 'we go through a checklist', closing that gap is manual work that would come to you.
Are the hardware and the main software under support contracts, and when do the big ones come up for renewal?
Why ask it
Out of warranty, a failed part is a purchase order instead of a phone call. Renewals are also where the budget gets tested, so ask what happened at the last large one. It helps to know whether the admin is asked for an opinion or handed the result.
Which migrations or upgrades are under way right now, and how far along is each?
Why ask it
Ask who started each one and whether they are still here, since a migration inherited without its planner is mostly detective work. Then find out what the date hangs on, such as a lease ending or support running out. That tells you how hard the deadline is and how much of your first year is already spoken for.
Upkeep
How does patching work here: how often, with which tool, and who agrees to the downtime?
Why ask it
A schedule, a test group that goes first and a window the business has accepted add up to a working process. 'Whenever there is time' is the worrying reply, along with servers nobody is allowed to restart. Ask how far behind the furthest machine is.
When was a backup last restored, and was it a test or the real thing?
Why ask it
A backup job can report success every night and still produce nothing that restores, so a restore is the only real evidence. You want a recent date and a rough idea of how long it took. If no one can remember, ask whether scheduling restore tests could be one of your first jobs.
Is there a copy of the backups that someone with full access to the network could not delete or encrypt?
Why ask it
Leave product names and locations out of it, since they should not tell a stranger those. What matters is whether anyone has thought about an attacker reaching the backups along with everything else. If the answer is vague, raise it again before you accept, because the recovery would fall to you.
Is there a disaster recovery plan, and has anyone ever run through it?
Why ask it
Follow up by asking what went wrong in the exercise. Being able to name something that failed in a test means the plan has met reality. A document last opened years ago is a starting point at best.
What is monitored today, and what did the team last learn about only because a user called?
Why ask it
The second half is what gets a straight answer. Every team has a blind spot, and one that can name its own, such as an expired certificate or a full disk, is paying attention. Then ask how many alerts fire on a normal day and how many need anyone to act.
Who finds the security vulnerabilities, and who is expected to fix them?
Why ask it
In many places a security team scans and hands the admins a list, so ask how long the list is and who puts it in order. With no security person at all, the whole subject lands on the admin. In that case ask what it is meant to include and whether money comes with it.
Who has administrator or root access right now, and how is it handed out and taken back?
Why ask it
A short list of named people, each with an admin account of their own and a record of what was done with it, is the healthy version. Everyone signing in as the same root or administrator user means nobody can say who changed what. Ask how access is removed when an admin or a contractor leaves, which hints at how much pushback tightening things would meet.
Has there been a serious outage or security incident in the last couple of years, and what changed afterward?
Why ask it
They may not be free to tell you everything, and that is reasonable. What you hope to hear is something concrete that changed, such as a new backup target or a second login factor. When the account keeps coming back to whose fault it was, expect your own first mistake to be handled the same way.
Which audits or compliance rules apply to these systems, and what do they ask of the admin?
Why ask it
Evidence for auditors tends to come from the admin: patch reports, access reviews, proof that a restore was tested. Which rules apply varies with the industry and the country, so let them tell you instead of guessing. A team that can name the frameworks and the dates is prepared, and a scramble in the week before the auditor arrives usually means the admin scrambling.
Changes
Who signs off on a change to a production system, and how long does approval usually take?
Why ask it
Answers run from 'you decide' to a weekly change board, and each has a cost: deciding alone means carrying the blame alone, and a board means waiting. Ask how the last emergency change was approved, since that shows how the process bends under pressure.
Is there a test or staging environment, or do changes go straight to production?
Why ask it
Plenty of smaller shops have none. If that is the case here, ask how they lower the risk: a snapshot first, one server before the rest, a quiet hour. If all you hear is 'we are careful', ask whether you could build somewhere to test.
How do the admins and the developers divide production: who deploys the applications, and who gets called when one falls over?
Why ask it
Skip this where the company writes no software of its own. Where it does, the boundary decides a lot of your nights: developers who deploy and answer for their own releases leave you the platform underneath. If they hand over a package and go home, you would be paged for code you have never seen, so ask what you could send back to them.
What happened the last time a change went wrong?
Why ask it
Ask for the story: how it was noticed, how it was undone, and what was said to whoever made the change. The version you want is unhurried and ends with a fix to the process. If no example comes to mind, either very little changes here or mistakes are not discussed.
If I had to rebuild a key server from the documentation alone, how far would I get?
Why ask it
A concrete test draws a more honest reply than asking whether documentation exists. Runbooks that get updated along with each change are what you hope for. If it lives mostly in people's heads, ask whose, and whether writing it down would count as real work in your week.
How are servers built and configured: by hand, from images, or through configuration management and code?
Why ask it
The test is what happens when a server dies: rebuilt from a template in an hour, or pieced together from memory over a weekend. Hand-built machines also drift apart, so the same fix works on one and fails on the next. Hand-built is not a reason to walk away if the manager wants it changed and says so.
How much room is there to script the repetitive work, and what has the team already automated?
Why ask it
An example of a task someone scripted, and the hours it gave back, shows that automation is valued here. Where nobody scripts, you could make a quick mark or you could meet resistance. Ask which the manager expects, and how a new script gets reviewed before it runs.
On-call
How many people share on-call, and how often would it be my week?
Why ask it
Divide the year by the headcount as they answer: with two people, half of it is yours. With a single admin there is no rotation at all, so ask what happened the last time that person took a week off. 'We would work something out' means you would never be fully off.
How many after-hours calls came in last month, and what were they about?
Why ask it
Push for the count, because 'it is usually quiet' means different things to different people. A few real outages is ordinary. The same disk or job waking someone night after night is a problem nobody has had time to fix, so ask whether you could spend working hours on the cause.
How is on-call and after-hours work made up for: extra pay, time off in return, or neither?
Why ask it
What you are owed, if anything, turns on the employer, your contract and local law, and nothing on this page can settle it. Get this company's arrangement in writing with the offer. The detail may sit with the recruiter or HR, but put it to the manager once: an awkward pause is an answer too.
How quickly am I expected to respond to a page, and can I do it from a phone?
Why ask it
A fifteen-minute response and a one-hour response make for very different evenings. Check whether the expectation is written down anywhere. If you would need a laptop and a good connection within reach at all times, plan your on-call weeks around that before you say yes.
Does any of the work need someone physically on site, and who goes in when hardware fails at night?
Why ask it
Remote management and a contract for hands in the data center mean most nights can be handled from home. Without them, the person driving in is you. Ask how many sites there are, how far apart, and whether travel time is counted.
How much planned work happens on evenings and weekends, such as patching, upgrades and migrations?
Why ask it
Patch nights and cutovers do not show up in any count of on-call pages, so ask about them separately. Find out how many weekends it took last quarter and how early people were told. Work that is scheduled well ahead and returned as time off is a fair arrangement, and work announced on Friday afternoon is not.
Outside the rotation, who do users and executives contact when something breaks after hours?
Why ask it
There is often an unofficial on-call next to the official one: the admin whose cell number the boss has. One route in, such as a help desk line or a shared on-call phone, keeps it fair. 'They usually just text whoever they know' means everyone is on call all the time.
The job
How many tickets reach the admins in a usual week, and does a help desk take the first pass?
Why ask it
The mix matters more than the number. A queue of password resets and printer faults is a help desk job under another title, so ask what gets passed up to the admins and what stays below. Ask too whether walk-ups and direct messages are sent back to the queue, because work that is never ticketed cannot be counted when you ask for help.
In an ordinary week, how much of an admin's time goes to tickets and how much to project work?
Why ask it
Get last month's real split, not the intended one. Careful work such as a migration or a patch cycle does not survive a day of interruptions, so listen for anything that shields it: a schedule for who takes the queue, quiet mornings, a help desk that holds the line. If projects always lose, the old systems you heard about earlier are not getting replaced.
How many admins are on the team, and who looks after what?
Why ask it
Being the only admin and being one of six are different jobs. Alone, ask who would look over your changes and who you could turn to when stuck. On a team, ask whether people keep to Windows, Linux or cloud, and whether you would be held to one of them.
Who would I report to, and have they run systems themselves?
Why ask it
Reporting to a finance director or an office manager happens a lot in smaller companies and need not be a problem. It does mean translating every risk into money and time. Ask how the last request to spend on infrastructure was decided.
What access would I have on day one, and how long does a new admin usually wait for full rights?
Why ask it
Some places hand over the keys in the first hour and others take weeks of approvals. Slow is not wrong, but weeks without access are weeks of watching. Ask what the last new admin could do alone by the end of the first week, and whether on-call starts before or after full access arrives.
Is there a budget for hardware, licenses and tools, and who decides how it is spent?
Why ask it
A yearly figure, a refresh cycle and some say for the admins is the comfortable version. Hardware that runs until it dies, with every purchase argued from scratch, is the other kind. Ask what happens when a server fails outside the plan: a replacement ordered that day, or a month of approvals while you nurse the spare.
If I found a risk that needed money to fix, how would I make the case, and who would hear it?
Why ask it
This asks whether the admin has a voice above their own manager. Ask for a time a risk was raised and then funded. Where risks were raised and parked, find out whether they are written down with the name of whoever accepted them, so they do not become yours alone.
At my first review, what would you look at to decide whether the systems had been well run?
Why ask it
The best outcome in this job is that nothing happens, which is hard to show at review time. Uptime, projects delivered, ticket times and feedback from users are all fair measures. Where there is no answer yet, offer to send a short monthly note on what was patched, tested and prevented, and watch how the idea lands.
Does the company pay for training or certifications, and where have admins here moved on to?
Why ask it
Ask what the last person spent it on, which shows whether the budget is real. A spare server or a cloud sandbox to break things in can be worth as much as a course. On the second half, 'admins here tend to stay admins' is fine if that suits you.
Is there a platform or tool in this environment that you wish I had more time on?
Why ask it
Keep this for last. Naming the technology makes this easier for the manager to answer than a general request for doubts. If it is Linux, the cloud side or sheer scale, say what you have run that comes closest and how you would get up to speed, then leave it there.
Hiring side
Which system in your current job would you least want to be paged about, and why?
Why ask it
A good opener for the manager's side of the table, because it cannot be answered from a textbook. Someone who really runs the environment names a system at once and explains what makes it fragile: no failover, one person who understands it, a vendor who is slow to answer. Vague answers suggest they worked near the systems more than on them.
A service will not start after a reboot. Talk me through how you find out why.
Why ask it
Listen for the order: read the error and the logs, check what the service depends on, ask what changed before the reboot. The exact commands matter less than whether they look before they act. Reinstalling as a first move is the weak answer.
A disk on a production server is at 95 percent and climbing. What do you do right now, and what do you do next week?
Why ask it
The first half is about buying time safely: find what is growing, clear what is known to be disposable, tell whoever depends on the server. The second half separates candidates. You want to hear about the cause, an alert at a lower threshold and a look at whether other servers are heading the same way.
How would you patch a server the business says can never go down?
Why ask it
Strong candidates question the 'never' before they answer: a server that cannot be restarted for patching cannot survive a hardware fault either. From there, expect talk of a second node, a negotiated window and a tested way back. Be cautious of anyone who would simply leave it unpatched, or patch it unannounced.
If a server were lost completely, what would you need in hand to rebuild it, and in what order would you bring things back?
Why ask it
This shows whether they have thought past the backup tool. A full answer includes the things people forget, such as license keys, credentials kept somewhere other than the lost machine, and the services everything else needs first, like sign-in and name resolution. Ask whether they have ever done it for real.
You inherit forty servers and no documentation. How do you find out what each one does and what depends on it?
Why ask it
Change the number to match your own estate. Careful candidates look before they touch: what is listening, what connects in, which scheduled jobs run, who logs on. They also ask people, and they do not switch something off to see who complains unless it can be switched back within minutes.
How do you decide which alerts are allowed to wake someone up?
Why ask it
The principle to hear is that a page should mean a person has to act now. Candidates who have carried a pager talk about the alerts they deleted or demoted to a morning report. Someone who wants an alert on everything has probably not spent a month being woken for things that could have waited until morning.
What have you chosen not to automate, and why?
Why ask it
Most candidates can list what they scripted. The ones with judgment can also name a task they left manual because it was rare, risky or needed a person to look first. Follow up by asking how they would know if one of their scheduled scripts quietly stopped working.
Tell me about a change you rolled back. How did you know it was time to stop trying to fix it in place?
Why ask it
People who have done this work for a while have one, and telling it plainly is a good sign in itself. Listen for a limit set before the change began, such as a time by which it had to work, and for a way back that had been tested. Pressing on for hours with no plan is the pattern to notice.
A developer asks for root on a production server to debug a problem. How do you handle it?
Why ask it
It tests whether they can protect the system without becoming the obstacle. Workable answers include doing it together on a shared session, pulling the logs for the developer, or granting access that expires and is recorded. A flat no and a shrugged yes both tell you how they would get on with your developers.
How do you keep track of certificates, service accounts and anything else that expires?
Why ask it
Expired certificates and lapsed service passwords cause outages that are entirely avoidable, so whether someone tracks them is a fair test of how tidy they are. Any system counts, from a monitoring check to a calendar, as long as more than one person sees the reminder. 'I just remember' works until the week they are away.
How to use these questions in a sysadmin interview
Practical guidance for the conversation itself
Before the interview
Find out how much of the title is servers
A system administrator at one company racks hardware and patches hypervisors. At another the same title means cloud consoles and scripts, and at a third it means the whole IT function for forty people, printers included. The posting usually gives it away in what it names: operating systems, a hypervisor, a cloud provider, a ticketing tool, an on-call line. Weight your questions to match. If you would be the only admin, lean on Upkeep and The job, since nobody else will catch a missed backup or argue for the budget.
Split the list between the manager and the admins
Technical rounds are often run by the admins you would work beside, with the manager in a separate conversation. Use that. The admins know how often the pager goes off, which server everyone avoids and how good the runbooks are. The manager knows the budget, who signs off on changes and what the role will be judged on. A recruiter can usually say how after-hours work is paid and little else on this page.
Have three you will ask whatever happens
Question time at the end of a technical interview can be short, and a panel that has spent an hour testing you may be ready to wrap up. Choose three questions from different groups and ask them even if time is tight. For many sysadmin jobs the ones that decide things are how often you would be on call, whether a restore has been tested and who you would report to. The rest of the page is for when an answer opens a door.
Know your own limits before you hear theirs
Some answers rule a job out for one person and are fine for another: being the only admin, on-call every second week, a server room you must be able to reach within the hour. Decide where you stand on those beforehand and write it down. A manager you like can make a two-person rotation sound temporary.
In the room
Ask for dates and counts
The most useful answers on this page are dates and numbers: when a backup was last restored, how far behind the oldest patch is, how many calls came in after hours last month, how many people share the rotation. Policies sound alike everywhere, and rough figures are enough. If the interviewer has to go and check, that is fine, and a reason to follow up by email.
Turn their technical questions around
A technical round hands you openings. Once you have explained how you would chase a full disk or test a restore, ask how it is done here. The moment is natural, it shows interest in their systems, and you may get a franker answer in the middle of a conversation than in the formal question time at the end.
Leave their secrets alone
An interviewer who will not tell a stranger which versions they run, where the backups sit or how the network is laid out is doing the right thing. Ask about the practice and leave the specifics alone: whether restores are tested, not where the copies are. If they offer to show you a diagram later in the process, take that as a good sign.
Reading the answers
An honest mess is better than a tidy story
No environment is clean. A manager who says the patching is behind, the documentation is thin and here is what they want done about it is describing a job you can succeed in. One who says everything is in good order has either a remarkable team or a limited view of it, so ask one more question before you decide which.
Do the on-call sum
Take the size of the rotation, the calls last month and the weekends of planned work, and turn them into nights and weekends per month. Two admins, six calls and a patch weekend is a different life from six admins and a quiet pager. Do the sum before you compare salaries, because the offer letter will not do it for you.
Ask how pay and hours work here
How on-call, overtime and weekend work are paid depends on the employer, the contract and where you live. Nothing on this page can tell you what you are owed. Ask how it is handled at this company, ask to see it in the written offer, and check anything that matters to you with whoever advises on employment where you are.
Sort the gaps into fixable and fixed
Afterward, list what was missing: untested restores, thin documentation, hand-built servers, a two-person rotation. Then mark which ones you would be given time and money to fix and which are simply how the place runs. A long list with a manager who wants it shortened can be a good job for the right person. Gaps nobody plans to close are the conditions you would work in.
If you are the one hiring
Describe your real environment first
Spend two minutes on what the candidate would inherit, including the awkward parts. Their answers to the Hiring side questions become more useful when they can relate them to your systems, and you avoid hiring someone who leaves in month three because the job was not the one described.
Make the scenarios yours
The disk, the reboot and the forty servers are placeholders. A failure from your own environment works better, because the questions the candidate asks back then have real answers, and you can watch what they do with them.
Stay on one answer
Whether it is a scenario or something that happened to them, stay with it for a few follow-ups: what they would look at next, who they would tell, what they would do if that did not work. Depth on one problem shows more than a line each on six.
Leave the trivia out
Port numbers and command flags are a search away for anyone doing the job, and a candidate who says they would look one up is describing how the work is really done. Spend the time on what cannot be looked up: what they check first, what they leave manual, when they say no.