Mock interviews by role · Software & Engineering
Systems Engineer mock interview
Systems interviews ask how a machine, a network path, or a batch job fails, and how you change it without taking the business down. They are closer to operations and reliability than to feature design.
Answer with what you observed, what you changed, and how you knew the change worked. A tool list without an observation is a weak answer.
What the loop usually looks like
Screen
30 min
An environment you run and a change you rolled out.
Troubleshooting
45 min
A scenario: disk full, packet loss, or a job that did not finish.
Process
30 min
Change windows, access, and how you document.
What interviewers score
- Observation before change
- Blast radius
- Repeatable changes
- Clear handoff
10 systems engineer interview questions and model answers
Technical
1. A server is up but users say the app is unreachable. What do you check, in order?
What they are testing: Layered troubleshooting.
I check whether the process is listening, whether local requests succeed, then DNS, then the path from the user through the load balancer. I do not reboot first. The first check that fails tells me where to go next.
Technical
2. Disk usage hit 100 percent overnight. How do you recover without deleting the wrong files?
What they are testing: Safe recovery.
I find the directory that grew, usually logs or a stuck job. I compress or move the oldest files to free space, then restart only the service that was blocked. I add an alert before 90 percent so the next one is not an outage.
Domain
3. How do you roll out a configuration change to a fleet?
What they are testing: Change control.
I change a canary, watch the health check, then proceed in batches. The previous config is one command away. I do not edit production hosts by hand in a way I cannot repeat.
Technical
4. How do you tell a network problem from an application problem?
What they are testing: Isolation.
If a simple connection to the port fails from outside but succeeds locally, I look at firewall, routing, or the load balancer. If the connection works and the response is wrong, I look at the application. I keep those two cases separate.
Situational
5. A vendor patch is marked urgent during a freeze. What do you do?
What they are testing: Risk trade-off.
I read what the patch fixes and whether we are exposed. If it is remote code execution on a reachable service, I take a short window and patch the exposed hosts first. If we are not exposed, I schedule it and write down why it waited.
Behavioral
6. Tell me about a change that caused an outage you then fixed.
What they are testing: Ownership.
A config push removed a route. I reverted the push, confirmed traffic, and then added a diff check so a route deletion requires an explicit flag. I included my name in the timeline.
Technical
7. What do you monitor on a Linux host that runs a critical job?
What they are testing: Useful signals.
Disk, memory pressure, whether the job process is running, and whether it produced the expected output. CPU average alone is not enough. The alert should mean the job did not finish, not that a chart looks busy.
Behavioral
8. Describe how you handed a system to another person.
What they are testing: Documentation that is real.
I wrote how to restart it, where logs are, and the one failure we already know. I sat with them for one change. A wiki page nobody used did not count as a handoff.
Domain
9. How do you handle shared admin passwords you inherited?
What they are testing: Access hygiene.
I replace them with personal accounts and a break-glass credential stored where access is logged. I revoke the shared password the same week. I do not leave it because the runbook mentions it.
Situational
10. Two teams blame each other for a slow path. How do you settle it?
What they are testing: Evidence.
I take a timestamped trace from the client to the service and show where the time went. The conversation moves to that hop. Blame without a trace is not a diagnosis.
Frequently asked questions
Is this the same interview as DevOps?
They overlap. Systems roles lean toward hosts, networks, and change windows. DevOps roles lean toward the developer pipeline. Use the posting’s verbs to decide which stories to lead with.
How deep should Linux answers go?
Far enough to say which command you ran and what you expected to see. You do not need to recite every flag.
What if my experience is a homelab or a degree lab?
Use it if you can describe a real failure. Say it was a lab. Inventing a production outage is worse than a true smaller story.
How do I practice troubleshooting out loud?
State the next check and why, then the result you would act on. A systems mock will interrupt you if you jump to a fix.