Why pre-screen system administrators before the technical interview
Nobody notices good system administration, which is exactly why it is hard to hire for. The habits that matter, testing restores, revoking accounts when people leave, patching before something forces it, produce no visible output until the day they are missing. Certifications do not distinguish them either. A short screen asks the questions whose answers only exist if the work was actually being done, starting with the last time a restore was tested.
What actually matters when screening System Administrator candidates
- 01
Technical proficiency
Check depth in the stacks they actually run: Linux package management and systemd, Windows Server and Active Directory, Group Policy, DNS and DHCP, plus scripting in Bash, PowerShell or Ansible.
- 02
Systems and trade-offs
Probe how they sized infrastructure: VM density on ESXi or Proxmox, RAID and storage choices, backup retention with Veeam or Borg, tested RTO and RPO targets.
- 03
Evidence and rigour
Test their evidence habits: monitoring with Zabbix, Nagios or Prometheus, log review in journalctl or Event Viewer, patch cycles, and how they proved a fix worked.
- 04
Collaboration and communication
Assess ticket-side behaviour: writing runbooks and knowledge base articles, handling escalations in Jira Service Management or Freshservice, and explaining downtime windows to non-technical staff.
Pre-screening questions to ask System Administrator candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems they ran
3 questions01What is your experience managing and maintaining computer systems and networks?
Listen forScale stated in servers and users, with what they owned outright rather than supported alongside a larger team.
Scale left vague, or a role that turns out to be first-line support rather than system ownership.
02What specific operating systems do you have experience with?
Listen forReal depth in at least one, with the versions and the administration work they did rather than a list of names.
Equal expertise claimed across every platform, or familiarity that stops at the desktop version.
03Are you familiar with setting up and managing servers?
Listen forBuilds they performed themselves, including how they document a configuration so someone else can rebuild it.
Servers built by hand with no record of the configuration, or setup work done only from a runbook.
Restores actually tested
2 questions04Can you detail your experience with data backup and recovery procedures?
Listen forA date for the last test restore and what it revealed, with retention and offsite copies described concretely.
Backups configured but never restored, or no idea how long a full recovery would actually take.
05Do you have experience with disaster recovery planning and testing?
Listen forA plan that was exercised rather than written, with recovery targets stated and a gap the test exposed.
A recovery document nobody has tested, or recovery targets that have never been measured against reality.
Access under control
3 questions06What types of system security measures are you familiar with implementing?
Listen forMeasures they put in place with the trade-off named, such as what patching or lockdown cost users in practice.
Security described as products installed, or measures listed with no implementation behind them.
07Have you managed remote systems access, and what security measures did you apply?
Listen forRemote access controlled with multi-factor authentication and logging, plus a clear position on shared administrative accounts.
Administrative access exposed directly to the internet, or shared credentials used across the team.
08Are you comfortable managing user accounts, password resets and account permissions?
Listen forA leaver process that revokes access on the day, with periodic review of who still holds elevated permissions.
Access granted on request with no review, or leaver accounts left active for weeks after departure.
Behaviour in an outage
4 questions09How would you handle a situation if an entire system went down?
Listen forCommunication first, then diagnosis with evidence preserved before changes are made, and a stated point for escalating.
Starts changing configuration immediately, or no plan for telling users what is happening.
10How have you handled difficult troubleshooting scenarios in previous roles?
Listen forA specific problem with the hypotheses ruled out in order, and the point where their first theory turned out wrong.
Problems solved by rebooting or reinstalling, with the cause never established.
11Can you describe your experience with system monitoring, analysis and performance tuning?
Listen forMonitoring that alerts before users notice, with a specific problem caught early and what threshold caught it.
Monitoring that only reports after an outage, or alerts so noisy that the team stopped reading them.
12Do you have any experience with scripting languages for task automation?
Listen forScripts written to remove a recurring manual task, with the time saved and where the scripts are kept.
Automation described as running other people's scripts, or scripts held only on their own machine.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names specific distros, AD forest structures and automation playbooks, and explains commands or cmdlets used rather than describing tasks generically.
Systems and trade-offs
25%5Weighs uptime against cost and complexity, cites a restore they actually tested, and admits where a design choice later caused trouble.
Evidence and rigour
25%5Traces an outage from alert threshold to root cause using logs and metrics, then names the change that stopped recurrence.
Collaboration and communication
15%5Shows documentation others reused, communicates maintenance windows clearly, and describes handling an angry user without dropping the change process.
Nothing about this job is visible until it is missing, and a certificate does not show whether a restore was ever tested. A one-way video screen asks directly.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for a system administrator take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish the scale of what they ran, hear one real outage, and check whether backups were ever restored rather than just configured.
How much weight should certifications carry?
Some, as evidence of breadth, but not as evidence of operational habit. Certifications test knowledge of features. The screen tests whether someone tested a restore, revoked a leaver's access, or patched before an incident forced it.
Evaluating answers
What is the strongest signal when screening a system administrator?
When they last restored from backup as a test. Administrators who run real systems have a date and a result, including a restore that failed. Anyone who has only configured backups has an untested assumption, not a recovery plan.
How do I judge outage answers?
Listen for what they did before touching anything: who they told, what they checked, and whether they preserved evidence of the cause. Administrators who start changing things immediately fix the symptom and lose the diagnosis.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
