Six question sets for the employer deciding what to ask: screening, infrastructure fundamentals, cloud and change control, a live outage scenario, security and recovery, and a paid work sample with a weighted scorecard. Every question carries why it is worth asking and what a strong answer sounds like. Download as DOCX.
The first system engineer a small business hires usually becomes the only person who understands how anything is wired together. That is what makes the interview hard. You are assessing depth you cannot personally verify, for a role that will hold administrative access to every server, every backup, and every account you own.
I watched a founder run this interview once with no technical background and no plan. The candidate named a dozen technologies, everyone nodded, and the offer went out that week. Three months later a drive failed and nobody could restore the backup that had been running green the whole time. The problem was never the founder's lack of technical knowledge. It was that nobody had asked the one question that would have exposed it.
At FirstHR we build for companies that hire without an HR department, where the owner or the operations lead runs the whole process alone. This page is written for that person: six question sets for the employer deciding what to ask, each question paired with why it is worth asking and what a strong answer sounds like, plus a paid work sample brief and a weighted scorecard.
TL;DR
Interview a system engineer on five things: infrastructure fundamentals, cloud and change control, how they behave during an outage, security and recovery, and small-team fit. Ask every candidate the same questions in the same order, push one level deeper on every answer, add a short paid work sample, and score on a weighted rubric. Six sets download as DOCX.
What a System Engineer Does at a Small Business
A system engineer designs, builds, and maintains the servers, networks, storage, identity, and cloud services a company runs on. At a small business the title almost always means an infrastructure generalist: they choose what to build, build it, automate the routine parts, keep it patched and backed up, and answer the phone when it breaks.
The engineer and administrator titles overlap heavily, and the distinction matters mainly because it changes what you should ask. Decide before you write the questions whether the job leans toward design and build or toward run and maintain. If it leans toward maintenance, the system administrator question set fits better, and the systems engineer job description is the place to pin down scope before you post.
Expectation
System Engineer
System Administrator
Specifies and designs new infrastructure
Evaluates on-premise, virtual, and cloud tradeoffs
Automates provisioning and configuration
Patches, monitors, and backs up the environment
Handles day-to-day user support
At a small business, does all of the above
The last row is the honest one. If you are hiring your first infrastructure person, they will do every job in the table, so interview for breadth and for judgment about what to leave alone. A specialist who has only ever owned one layer inside a large team is a common and expensive mismatch at this size.
What to Test, and in What Order
Test five things in a deliberate order: ownership, infrastructure fundamentals, change discipline, incident behavior, and security and recovery. Running them in that order saves time, because the screening call filters out candidates who described someone else's environment before anyone books a ninety-minute technical round.
Screening and Fit
30-minute first call
What they personally built versus inherited, whether they can be the only technical person, and what they automate. Run this before anyone books a technical round.
Infrastructure Fundamentals
The weekly work
Operating systems, networking, storage, virtualization, identity, patching, and monitoring, with what a strong answer sounds like so a non-technical interviewer can judge depth.
Cloud and Automation
Build and change safely
Cloud ownership, spend control, infrastructure as code, secrets handling, and how they make a risky change on a system you cannot afford to lose.
Troubleshooting and Incidents
The highest-signal set
A live outage scenario plus follow-ups on escalation, communication, and the write-up afterward. How someone behaves in a failure beats any certification.
Security and Recovery
They hold the keys
Backups they have actually restored, ransomware defense, privileged access, technical offboarding, and audits. Part of the hire, not a specialist add-on.
Work Sample and Scorecard
Score, do not guess
A paid two-hour work sample brief, a weighted 1-to-5 rubric, and a red-flag checklist, so the decision rests on written evidence rather than a confident conversation.
Weight the Sets to the Job You Are Actually Filling
If your infrastructure is mostly on your own hardware, weight fundamentals, incidents, and recovery, and treat the cloud set as a bonus. If you are mid-migration or already cloud-first, weight cloud and change control heavily and keep the fundamentals set short. If the hire will also handle user support, add a few questions from the administrator set. What you must not do is drop the security and recovery set: it is the one that protects the business, and it is the one candidates are least rehearsed for.
Six Question Sets to Download
Download all six as one Word document or copy the sets you need. Each question lists why it is worth asking and what a strong answer sounds like, so a non-technical interviewer can score it. The final file holds the paid work sample brief, the weighted scorecard, and the red-flag checklist.
Download All 6 Question Sets and the Scorecard
Screening, fundamentals, cloud and change control, incidents, security and recovery, plus a work sample brief and weighted rubric. All in one DOCX.
Set 1: Screening and Small-Team Fit
A 30-minute first call: what they own today, what they built rather than inherited, whether they can be the only technical person, and what they have automated recently.
Screening and Small-Team Fit Questions
SYSTEM ENGINEER INTERVIEW: SCREENING AND SMALL-TEAM FIT
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Run this as a 30-minute first call before anyone spends an afternoon on a deep
technical round. The goal is to find out what the candidate has personally built
and owned, and whether they can work as the only infrastructure person on a small
team. Ask the same questions of every candidate and take notes as you go.
QUESTIONS
1. Describe the environment you own today: how many servers, which operating
systems, on-premise or cloud, and how many people share responsibility for it.
Why ask: it sets the scale of everything else they say and exposes candidates
who describe a team’s work in the first person.
Strong answer: concrete counts, named platforms, and a clear line between what
they built, what they inherited, and what a colleague ran.
2. What did you build from nothing, rather than inherit and maintain?
Why ask: a small business needs someone who can design and stand things up,
not only follow an existing runbook.
Strong answer: at least one system they specified, built, documented, and
handed over, with the reasons behind the design choices.
3. Have you ever been the only technical person at a company? How did that go?
Why ask: this is the actual job at most small businesses, and some strong
engineers are miserable without a team around them.
Strong answer: honest about the tradeoffs, describes how they prioritized,
escalated, and bought outside help when a problem exceeded their depth.
4. What is currently on fire in your environment, and what would you fix first?
Why ask: it reveals judgment and honesty. Every environment has debt.
Strong answer: names real problems, ranks them by business risk rather than
by personal interest, and explains the ranking.
5. Walk me through the last thing you automated and how much time it saved.
Why ask: automation is the difference between one engineer covering a small
company and one engineer drowning in it.
Strong answer: a specific task, the tool used, and a believable estimate of
the time recovered.
6. What do you want to be doing in this role that you cannot do today?
Why ask: motivation predicts retention, and this role is expensive to refill.
Strong answer: a specific gap they want to close, matched to what you are
actually offering.
WHAT TO LISTEN FOR
•Says "I built" only about things they personally built
•Comfortable being the sole owner without becoming a bottleneck
•Ranks problems by business impact, not by technical interest
•Names tools with real detail, not as a list of buzzwords
NOTES
__
__
Set 2: Infrastructure Fundamentals
The main technical round: diagnosing a slow application, choosing between hardware and managed services, DNS, patching, identity and permissions, monitoring, and documentation.
Infrastructure Fundamentals Questions
SYSTEM ENGINEER INTERVIEW: INFRASTRUCTURE FUNDAMENTALS
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Use this in the main technical round. These questions cover operating systems,
networking, storage, virtualization, and identity: the layers a system engineer
touches every week. You do not need to grade the answers yourself. Each question
lists what a strong answer sounds like so a non-technical interviewer can judge
depth, and a technical friend or contractor can review your notes afterward.
QUESTIONS
1. A user says an internal application is slow. Walk me through how you find out
where the time is going.
Why ask: it tests layered thinking rather than guessing.
Strong answer: works through the layers in order (client, network, application,
database, host), checks metrics before changing anything, and forms a
hypothesis they can test.
2. How do you decide between running something on your own hardware, on a virtual
machine, in a container, or as a managed service?
Why ask: at a small business this decision sets your cost and your risk for
years.
Strong answer: weighs cost, recovery time, staffing, and compliance, and does
not default to whatever they used last.
3. Explain how DNS resolution works for a user opening your company website.
Why ask: DNS causes a disproportionate share of real outages, and the answer
shows whether they understand the systems they operate.
Strong answer: describes resolver, records, caching, and time to live, and
mentions why a cached record makes a change look like it failed.
4. How do you handle patching across servers and workstations without breaking
production?
Why ask: patching is where most small-business risk actually lives.
Strong answer: a schedule, a test group, a rollback plan, and a way to prove
what is patched and what is not.
5. How do you manage user identity, permissions, and offboarding across systems?
Why ask: access sprawl is the most common finding in a small-company audit.
Strong answer: a single source of identity, groups rather than per-person
permissions, least privilege, and a documented offboarding checklist.
6. What monitoring and alerting would you put in place in your first month here?
Why ask: a candidate who cannot answer this will find out about outages from
your customers.
Strong answer: monitors the things the business cares about, sets alerts that
a human can act on, and explicitly avoids alert noise.
7. How do you document what you build, and who is the documentation for?
Why ask: at a small business the documentation is the succession plan.
Strong answer: writes for the next person, keeps it near the system, and
treats it as part of finishing the work.
WHAT TO LISTEN FOR
•Diagnoses in layers instead of guessing
•Explains tradeoffs, not just preferences
•Thinks about rollback and blast radius before changes
•Treats documentation as part of the job
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Cloud ownership versus exposure, spend control, infrastructure as code, secrets handling, migrations that went wrong, and how they make a risky change safely.
Cloud, Automation, and Change Control Questions
SYSTEM ENGINEER INTERVIEW: CLOUD, AUTOMATION, AND CHANGE CONTROL
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Use this set if any part of your infrastructure runs in a public cloud, or if you
expect it to within a year. It also covers configuration management and how the
candidate makes changes safely, which matters just as much on your own hardware.
QUESTIONS
1. Which cloud platforms have you run in production, and what did you actually
operate there?
Why ask: exposure is not the same as ownership.
Strong answer: names the platform and the specific services, with the
problems they hit and how they solved them.
2. How do you keep cloud spend under control?
Why ask: an unmanaged cloud bill is one of the few IT costs that can grow
faster than a small business can absorb.
Strong answer: tagging, right-sizing, scheduled shutdown of idle resources,
budget alerts, and a specific example of a bill they reduced.
3. Do you define infrastructure as code, and what does your workflow look like?
Why ask: infrastructure as code turns a one-person setup into something that
can be reviewed, restored, and handed over.
Strong answer: describes a real repository, how changes are reviewed, and how
the code and the running environment are kept in step.
4. How do you make a risky change on a system nobody can afford to lose?
Why ask: this is the single best predictor of whether they will break your
business by accident.
Strong answer: a maintenance window, a backup or snapshot taken first, a
tested rollback, a written plan, and someone told in advance.
5. How do you manage secrets: passwords, keys, and certificates?
Why ask: secrets in a spreadsheet or a chat thread are a common small-company
failure and a real liability.
Strong answer: a dedicated secrets store, rotation, least privilege, and no
shared personal accounts.
6. What have you migrated, and what went wrong?
Why ask: every real migration goes wrong somewhere, and the answer shows
whether they have done one.
Strong answer: a specific migration, the surprise nobody planned for, and
what they changed in their process afterward.
WHAT TO LISTEN FOR
•Ownership of a production environment, not a training course
•Cost awareness without being asked twice
•Change discipline: backup first, rollback ready, plan written
•Secrets handled in a system, not in a document
NOTES
__
Set 4: Troubleshooting and Incident Response
A live Monday-morning outage scenario you read out and let the candidate drive, plus follow-ups on escalation thresholds, communicating with staff, and the write-up afterward.
Troubleshooting and Incident Response Questions
SYSTEM ENGINEER INTERVIEW: TROUBLESHOOTING AND INCIDENT RESPONSE
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
This is the highest-signal set in the kit. How someone behaves during a failure
tells you more than any certification. Run question 1 as a live scenario: read it
out, then answer their questions as if you were the person reporting the problem.
Let them drive for ten minutes and watch the sequence of their thinking.
LIVE SCENARIO
1. It is 9:15 on a Monday. Staff cannot reach the file server or the accounting
system. Email works. Nobody changed anything over the weekend, as far as you
know. You are the only technical person. Go.
Why ask: it is exactly what your first bad morning will look like.
Strong answer: establishes scope first (who, where, which services), checks
the shared dependency rather than the loudest symptom, communicates a holding
message to staff early, and states what they would check in what order and
why. They ask you questions instead of guessing.
Weak answer: starts rebooting things, jumps to a favorite cause, or goes
silent and works alone while nobody knows what is happening.
FOLLOW-UP QUESTIONS
2. Tell me about the worst outage you have handled. What actually caused it?
Why ask: specificity separates lived experience from stories.
Strong answer: a real timeline, the true root cause, and the part they got
wrong along the way.
3. How do you decide when to keep digging and when to call in outside help?
Why ask: a sole engineer who never escalates is a risk to the business.
Strong answer: a time or impact threshold agreed in advance, and no ego about
using a vendor’s support contract.
4. What do you tell non-technical staff during an outage, and how often?
Why ask: at a small company, communication is half the job.
Strong answer: an early plain-language message, a stated next update time, and
no promises about a fix time they cannot keep.
5. What do you do after the system is back up?
Why ask: engineers who skip the write-up repeat the outage.
Strong answer: a short blameless write-up, a fix for the cause, and a change
to monitoring so the next one is caught earlier.
6. Describe a time you caused an outage yourself.
Why ask: everyone has. The answer tests honesty and self-awareness.
Strong answer: owns it plainly, explains the process change that followed, and
does not blame a colleague or a vendor.
WHAT TO LISTEN FOR
•Scope before cause, cause before fix
•Communicates early and sets the next update time
•Escalates on a threshold, not on emotion
•Writes it up and changes something afterward
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Restores they have actually performed, recovery objectives, ransomware defense, privileged access including their own, technical offboarding, and audit experience.
Security, Backup, and Recovery Questions
SYSTEM ENGINEER INTERVIEW: SECURITY, BACKUP, AND RECOVERY
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
A system engineer holds the administrative keys to everything you own, so
security practice and recovery discipline are part of the hire rather than a
specialist add-on. These questions work for any small business, whether or not
you have a compliance requirement.
QUESTIONS
1. When did you last restore from backup, and what did you restore?
Why ask: this is the most revealing question in the whole kit. A backup nobody
has restored is a hope, not a backup.
Strong answer: a recent restore, tested on a schedule, with the time it took.
Weak answer: describes the backup job in detail and cannot name a restore.
2. What are our recovery time and recovery point objectives likely to be, and how
would you find out?
Why ask: it tests whether they connect technical design to business tolerance.
Strong answer: asks how long the business can be down and how much data it can
lose, then designs backwards from those answers.
3. How would you protect a small company against ransomware?
Why ask: small businesses are targeted precisely because they are lightly
defended.
Strong answer: offline or immutable backups, least privilege, patching,
multi-factor authentication, email filtering, and a tested recovery plan.
4. How do you handle privileged access, including your own?
Why ask: the person answering will hold the most powerful account you have.
Strong answer: separate admin accounts, multi-factor authentication, no shared
credentials, logging of privileged actions, and comfort with being audited.
5. What does offboarding look like technically when someone leaves?
Why ask: forgotten accounts are a standing risk and a common audit finding.
Strong answer: a checklist covering identity, devices, third-party tools,
shared credentials, and data handover, run on the last day.
6. Have you supported an audit or a compliance requirement? Which one?
Why ask: relevant if you handle regulated data or answer customer security
questionnaires.
Strong answer: names the framework, what evidence they had to produce, and
what they changed to produce it.
7. If I gave you one month and a small budget, what would you fix first here?
Why ask: it turns security from theory into a plan you can act on.
Strong answer: prioritizes by realistic risk to your business, not by what is
fashionable.
WHAT TO LISTEN FOR
•Has actually restored, recently, and knows how long it took
•Designs from business tolerance rather than from a product
•Treats their own admin access as something to be controlled
•Prioritizes by risk and cost, not by fashion
NOTES
__
Set 6: Work Sample Brief, Scorecard, and Red Flags
A two-hour paid work sample brief you can send as written, a weighted 1-to-5 rubric, and the red-flag checklist. This is the part most question lists leave out.
Work Sample Brief, Scorecard, and Red Flags
SYSTEM ENGINEER WORK SAMPLE, SCORECARD, AND RED FLAGS
Candidate: __
Interviewer: __
Date: _
PART 1: WORK SAMPLE BRIEF (2 HOURS, PAID)
Send this after the technical round to your final two candidates. Pay for the
time, use a sanitized version of your real environment, and give everyone the
same brief and the same time budget.
Brief to send:
"Here is a description of our environment: [servers, cloud services, number of
staff, what we cannot afford to lose]. Write a one-page plan covering: the three
biggest risks you see, what you would do in the first 30 days, what you would
need from us, and one thing you would deliberately leave alone for now. Two hours
maximum. We will pay for your time either way."
How to grade it:
•Did they ask clarifying questions before starting? (Good sign.)
•Are the risks the real ones, or generic advice that fits any company?
•Is the 30-day plan sequenced, or a wish list?
•Did they name something to leave alone? Restraint is a senior trait.
•Is it written so a non-technical owner can act on it?
PART 2: SCORECARD (SCORE EACH AREA 1 TO 5)
5 = strong, specific evidence 4 = solid evidence 3 = some evidence
2 = weak or mixed evidence 1 = no evidence or red flags
Note: every interviewer scores independently before the group discusses, so a
single confident voice does not anchor the decision.
Four Questions That Carry the Most Signal
If you only have time for four questions, ask these. Each one is hard to fake, each has a clear tell in the answer, and together they cover recovery, change discipline, real experience, and judgment. Everything else in the kit is depth on top of these.
When did you last restore from backup, and what did you restore?
Why ask it: Ask it because almost every small business has a backup job running and almost none have proved it works. The answer separates an engineer who tests recovery from one who trusts a green checkmark.
Strong answer: A restore they performed recently, on a schedule, with the time it took and what they found. They talk about recovery objectives and about restoring to a different machine, not just about the backup job.
Weak answer: A detailed description of the backup software and no restore they can name. Treat that as a serious finding, not a small gap.
How do you make a risky change on a system nobody can afford to lose?
Why ask it: Ask it because a sole engineer can take your company offline by accident on a Tuesday afternoon. This question predicts that risk better than any technical trivia.
Strong answer: A maintenance window, a snapshot or backup taken first, a tested rollback, a written plan, and someone told in advance. They mention blast radius and doing it outside business hours where possible.
Weak answer: Confidence that they do not break things, or a change process that exists only in their head. Speed without a rollback plan is the expensive kind of speed.
Tell me about the worst outage you handled. What actually caused it?
Why ask it: Ask it because specifics are hard to fake. The root cause, the timeline, and the mistakes along the way tell you whether they have lived through a real failure.
Strong answer: A concrete timeline, a true root cause rather than a symptom, an honest account of what they got wrong first, and a change they made afterward to monitoring or process.
Weak answer: A vague story with no cause, or a story where every decision they made was correct. Nobody handles a real outage perfectly.
What would you deliberately leave alone in your first 90 days?
Why ask it: Ask it because restraint is a senior trait and a new engineer with free rein can rebuild things that were fine while the real risks go untouched.
Strong answer: Names something that works, explains why rebuilding it is not the best use of the first quarter, and ties the answer to business risk rather than personal taste.
Weak answer: Wants to replace everything immediately, or cannot name anything worth keeping. That answer usually costs money in the first year.
The follow-up matters as much as the question. After every answer, ask some version of why that, what did it cost, or what broke. A candidate with real depth goes one level down each time you ask. A candidate without it repeats the same level of detail in new words, which is the clearest tell you will get in an hour.
How to Judge Depth When You Are Not Technical
Grade the process, not the technology. You cannot verify whether a candidate configured a firewall correctly three years ago, but you can absolutely tell whether they diagnose in layers, take a backup before a risky change, and know what they do not know. Those habits predict the job better than any specific tool knowledge.
Depth signals
Explains a tradeoff, not just a preference
Goes one level deeper when you ask why
Says what they do not know without hedging
Ownership signals
Says I built only about their own work
Names the surprise in a past migration
Documents so the next person can follow
Operational signals
Backup first, rollback ready, plan written
Monitors what the business cares about
Escalates on a threshold, not on ego
Red flags
Cannot name a backup they restored
Buzzword lists with no detail behind them
Blames users, vendors, or prior staff
Two mechanical tricks help. First, write the candidate's answer down in their own words, because vague answers look much vaguer on paper than they sound in the room. Second, ask the same question of every candidate and compare the written answers side by side, which is the core of a structured interview and the reason it outperforms a free-flowing chat.
What you hear
What it usually means
What to ask next
A long list of technologies
Exposure, not ownership
Which of those did you configure yourself, start to finish?
We had a process for that
They followed it, did not design it
Who wrote it, and what would you change about it?
It just started working again
No root cause was ever found
What would you do differently to find the cause next time?
I would need to look at your setup first
Good sign, not evasion
What would you look at first, and what would you expect to find?
I have not done that
Honesty, if it is rare
How would you approach it, and where would you get help?
Keep every completed scorecard in one folder rather than scattered across inboxes, so the final comparison is a document instead of a memory. Applicant tracking is coming soon to FirstHR, and until it lands a single shared spreadsheet with one row per candidate and one column per scoring area does the job for a two-round process.
The Work Sample That Beats a Whiteboard
Give your final two candidates a two-hour paid work sample built from your real environment, and skip the whiteboard entirely. Send a sanitized description of what you run and ask for a one-page plan: the three biggest risks they see, what they would do in the first 30 days, what they need from you, and one thing they would deliberately leave alone.
This format works for three reasons. It resembles the actual job, which makes it a defensible selection procedure under the EEOC guidance on employment tests. It produces something you can compare side by side. And it gives you a first-quarter plan for whoever you hire, written by them before they started.
Grade it on four things: whether they asked clarifying questions before starting, whether the risks are specific to you rather than generic advice, whether the 30-day plan is sequenced instead of a wish list, and whether an owner without a technical background could act on it. Pay for the time either way. Two hours of a senior engineer's time costs less than one week of a bad hire.
Fair, Legal, and Structured Interviewing
Keep every question tied to the job, ask the same core set of every candidate, and score against a written rubric. Those three habits are simultaneously the fairest approach, the most legally defensible one, and the one that produces better hires. In technical interviewing they matter more than usual, because fluency and depth sound alike early on.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Keep away from age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews have their own traps: do not ask what year someone graduated, do not ask how they feel about working with a younger team, and do not turn a conversation about on-call coverage into a question about childcare. Ask instead whether the candidate can meet the on-call and after-hours expectations of the role, which is job-related and applies to everyone. This is general information, not legal advice.
Same core questions, same order, every candidate
A structured interview, where every candidate answers the same questions and is scored against the same rubric, predicts on-the-job performance better than a free-flowing technical chat and reduces the chance that a decision rests on rapport. This matters more in technical hiring than almost anywhere else, because a fluent talker and a deep engineer sound similar for the first ten minutes. Write the questions before you meet anyone, ask them in the same order, and take notes in the same places. The six sets here are built to be used exactly that way, and the scorecard gives you a written record of why you chose the person you chose.
Test the skill you will actually pay for
Selection procedures, including technical tests and work samples, need to be job-related and consistent with business necessity, and the EEOC applies the same standard to a coding-style screen as to any other test. In practical terms: give every finalist the same brief, the same time budget, and the same grading criteria, and make the exercise resemble the work. Puzzle questions and whiteboard trivia fail both tests. They rarely reflect the job, and they are hard to score consistently. A two-hour paid plan for your real environment is more defensible and far more informative. This is general information, not legal advice.
Handle references and access checks properly
A system engineer will hold administrative access to your finance systems, your customer data, and your email, so reference checks and any background screening deserve real attention rather than a rubber stamp. Ask references specifically about change discipline, honesty during incidents, and how the person behaved when something broke. If you run a background check, follow the applicable federal and state rules on disclosure, authorization, and adverse action, and apply the same process to every candidate for the role. Consistency is both the fairer approach and the easier one to defend later. This is general information, not legal advice.
Structure Beats Conversation, and It Is Also the Safer Route
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC rules against basing decisions on protected characteristics. The scorecard is what turns that principle into a written record.
Avoid the traps specific to technical hiring: graduation years, questions about fitting in with a younger team, and on-call conversations that drift into family arrangements. Ask instead whether the candidate can meet the on-call expectations of the role, which is job-related and applies to everyone. Structure also reduces bias in the same motion. This is general information, not legal advice.
What to Pay a System Engineer
There is no single federal occupation for the exact title, so benchmark against the closest classification and adjust for your metro and the level you need. The spread between a junior generalist and a senior infrastructure engineer is very wide, which is why an honest range in the posting saves everybody time.
Median $116,580 a Year (BLS OEWS, May 2025)
Computer systems engineers and architects, reported within computer occupations, all other, had a median annual wage of $116,580, about $56.05 an hour, with the lowest 10 percent under $55,940, the 25th percentile at $79,370, the 75th at $157,500, and the highest 10 percent above $188,470, according to the U.S. Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025). Network and computer systems administrators, a closer match for a maintenance-heavy role, had a median of $99,130.
Level
Where to anchor
What you are buying
First infrastructure hire, junior
Near the 25th percentile
Hands-on maintenance with outside help on design
Generalist, 3 to 6 years
Between the 25th and 50th
Owns the environment end to end, alone
Senior, design and migration
At or above the median
Specifies architecture and leads a migration
Cloud or security depth
Above the median
In-demand skills with real production ownership
Two costs sit outside the salary line. After-hours coverage is real work, so decide whether you are paying for on-call or buying it from a managed provider. And classification is not a title question: the Fair Labor Standards Act computer employee exemption turns on duties and on a pay floor of $684 per week or $27.63 per hour, and a role that is mostly hands-on maintenance may not qualify. Check the duties test rather than the job title. This is general information, not legal advice.
Hiring Without an HR Department
At a large company this candidate meets three engineers who each probe a layer they know cold. At a small business the owner runs the interview alone, between everything else, and the hire will hold the keys to the whole company. Here is how to make one person's interview hold up anyway.
You are interviewing for depth you cannot personally verify
At a large company a system engineer meets three engineers who each probe a layer they know cold. At a small business the owner or the operations lead runs the interview alone, and the honest problem is that a confident wrong answer and a correct one sound identical. The way around it is not to become technical overnight. It is to ask questions whose answers reveal process rather than trivia, to push one level deeper every time (why that, what did it cost, what broke), and to put a short paid work sample in front of the final two. Then have a technical friend or your outsourced provider read the work sample and your notes. That costs a few hundred dollars and removes most of the guesswork.
This hire holds the keys to everything you own
A system engineer will end up with administrative access to your servers, your cloud accounts, your email, and often your finance systems, which makes trust and process part of the evaluation rather than an afterthought. Ask directly how they handle privileged access, whether they use separate admin accounts, and how they feel about privileged actions being logged. A good candidate treats all of that as normal. Then build the controls in from day one: an owner-held account you never give away, multi-factor authentication everywhere, a written list of every system and who has access to it, and a technical offboarding checklist you can run on someone’s last day, including your own engineer’s.
The interview is the easy part; the first 90 days decide the hire
Once you choose, the work shifts from evaluating to onboarding, and for this role that means access provisioning, a confidentiality agreement, and a first-quarter plan built from the work sample they already wrote. FirstHR fits the people side of that: send the offer for e-signature, run the new hire paperwork, drive the access and policy checklist as task workflows, and keep the signed documents on the employee profile where you can find them a year later. To be clear on scope, FirstHR is an onboarding and HR platform, not a monitoring, backup, or infrastructure tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
One more habit worth building: check references properly for this role. Ask specifically about change discipline, honesty during incidents, and how the person behaved when something broke. A reference check that asks those three things is worth more than four generic calls, and it is the cheapest verification available to a company without an HR team.
From Interview to First Day
Once you choose, the job shifts from evaluating to onboarding, and this role has extra steps because of the access involved. Send the offer letter with the on-call expectations written down, get a confidentiality agreement signed before any credential changes hands, and provision admin access deliberately rather than all at once on day one.
Offer and confidentiality agreement
Confirm role, pay, on-call expectations, and start date in writing, with a confidentiality agreement signed before any credential changes hands.
Provision access deliberately
Separate admin accounts, multi-factor authentication, an owner-held break-glass account, and a written record of every system granted.
Store the paperwork where you can find it
Signed offer, confidentiality agreement, I-9, W-4, and policy acknowledgments on one employee profile, not scattered across inboxes.
Run the first 90 days from their own plan
Turn the work sample they wrote into the first-quarter plan, with checkpoints at 30, 60, and 90 days.
Turn the work sample they already wrote into the first-quarter plan, with checkpoints at 30, 60, and 90 days. That gives a new engineer something concrete to deliver and gives you something concrete to review, which beats the usual arrangement where nobody knows whether the first quarter went well. The rest of the new hire paperwork should be done before the start date, not during it.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the paperwork, and the access and policy checklist in one place, and keeps the signed documents on the employee profile where you can still find them a year later. FirstHR is an onboarding and HR platform, not a monitoring, backup, or infrastructure tool, so pair it with those. Applicant tracking is coming soon to FirstHR, and until then a simple spreadsheet is enough to track candidates through the two rounds and the work sample. More hiring templates are in the hiring library.
Key Takeaways
Decide whether the role is design-and-build or run-and-maintain before you write a single question, because the two need different sets.
Ask when they last restored from backup and what they restored; a candidate who cannot answer has never tested recovery.
Test change discipline directly: a maintenance window, a backup taken first, a tested rollback, and a written plan.
Run a live outage scenario and watch the sequence: scope before cause, cause before fix, and communication throughout.
Give the final two a short paid work sample built from your real environment instead of whiteboard trivia.
Score every candidate on the same weighted rubric, independently, so a confident conversation does not decide the hire.
Benchmark pay against BLS data: the closest classification reported a median of $116,580 a year in May 2025.
Frequently Asked Questions
What questions should I ask a system engineer in an interview?
Ask questions that reveal process rather than trivia. The most useful ones for an employer are: describe the environment you own today and what you personally built in it; walk me through how you would diagnose a slow internal application; how do you make a risky change on a system nobody can afford to lose; when did you last restore from backup and what did you restore; tell me about the worst outage you handled and what actually caused it; and how do you handle privileged access, including your own. Add a live outage scenario and let the candidate drive it for ten minutes. Each of those has a clear signal attached, so a non-technical interviewer can score the answer. This page groups them into six downloadable sets, each question paired with why it is worth asking and what a strong answer sounds like.
What is the difference between a system engineer and a system administrator?
A system engineer leans toward designing and building infrastructure, while a system administrator leans toward running and maintaining it. In practice the titles overlap heavily, and at a small business one person usually does both jobs. The useful distinction for an interview is scope: an engineer is expected to specify what to build, evaluate tradeoffs between on-premise, virtualized, and cloud options, and automate the result, whereas an administrator is expected to keep the existing environment healthy, patched, backed up, and supported. Decide which side of that line your open role actually sits on before you write the questions, because the design questions and the operations questions test different things. If you are hiring a maintainer and interviewing for an architect, you will reject good candidates.
How do I evaluate a system engineer if I am not technical myself?
You do not need to grade the technology; you need to grade the process. Ask questions whose answers expose method rather than facts, then push one level deeper every time with why that, what did it cost, and what broke. Strong candidates go deeper comfortably and say plainly when they do not know something. Weak ones repeat the same level of detail in different words. Use the specific tells: a backup they have personally restored, a change process with a rollback, a real root cause from a real outage, and restraint about what to leave alone. Then give your final two candidates a short paid work sample based on your actual environment and have a technical friend or your outsourced IT provider review their submissions and your interview notes. That combination removes most of the guesswork for a few hundred dollars.
Should I give a system engineer a technical test?
Yes, but make it resemble the job rather than a puzzle. The most useful format for a small business is a short paid work sample: give the finalists a sanitized description of your environment and ask for a one-page plan covering the three biggest risks they see, what they would do in the first 30 days, what they would need from you, and one thing they would deliberately leave alone. Two hours is enough. Pay for the time, give every candidate the same brief and the same grading criteria, and grade whether the risks are real and the plan is sequenced. Selection procedures should be job-related and applied consistently, which a work sample built from your own environment satisfies far better than whiteboard trivia. The brief and the grading notes are included in the downloadable set on this page.
What are the biggest red flags in a system engineer interview?
The clearest red flag is a candidate who cannot name a backup they personally restored, because it usually means recovery has never been tested anywhere they worked. Others worth weighing: describing a team's work in the first person and then failing to go one level deeper; making risky changes without a backup or a rollback plan; dismissing documentation as busywork; blaming users, vendors, or previous staff for every past problem; discomfort with logging or auditing of privileged access; listing many technologies without being able to explain a single tradeoff in depth; and never escalating or asking for help. None of these is disqualifying on its own, but two or three together usually mean the environment they described was maintained by someone else. The downloadable scorecard includes the full red-flag checklist.
How much does a system engineer cost to hire?
There is no single federal occupation for the exact title, so benchmark against the closest classification. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), computer systems engineers and architects, reported within computer occupations, all other, had a median annual wage of $116,580, about $56.05 an hour, with the lowest 10 percent under $55,940, the 25th percentile at $79,370, the 75th at $157,500, and the highest 10 percent above $188,470. Network and computer systems administrators, a closer match for a maintenance-heavy small business role, had a median of $99,130. Most small businesses hiring a hands-on generalist land between the 25th and 50th percentiles, adjusted for their metro. Budget for the surrounding costs too: certifications, tooling, and after-hours coverage.
Is a system engineer exempt from overtime?
It depends on duties and pay, not on the job title. The Fair Labor Standards Act includes a computer employee exemption covering computer systems analysts, programmers, software engineers, and similarly skilled workers whose primary duties involve systems analysis, design, or programming, provided they are paid at least $684 per week on a salary basis or $27.63 per hour. The exemption does not extend to employees who merely use computers, or to those engaged in manufacturing or repairing hardware, and a role that is mostly hands-on maintenance and user support may not qualify even at a high salary. Because the analysis turns on what the person actually does day to day, classify the role against the specific duties test rather than the title, and check with an employment attorney if it is close. This is general information, not legal advice.
How many interview rounds does hiring a system engineer take?
Two rounds plus a work sample is enough for most small businesses. Round one is a 30-minute screening call about the environment they own, what they personally built, and whether they can work as the only technical person. Round two is a 60 to 90 minute technical interview covering infrastructure fundamentals, cloud and change control, security and recovery, and a live outage scenario you run as a conversation. Then send a short paid work sample to your final two and make the decision from the scorecard. Adding a fourth or fifth round rarely improves the decision and does cost you candidates, because strong infrastructure engineers usually have other offers moving. Move quickly, keep the questions the same for everyone, and score immediately after each conversation while the answers are fresh.
