The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Strong Linux troubleshooting answers show a method, not just a command: define the symptom and scope, gather read-only evidence, test one explanation at a time, make the smallest safe change, then verify recovery. These ten practical scenarios are representative interview prompts, not a ranking of the questions employers ask most often.
1. A Linux server has become slow. What do you check first?
Start by observing the system rather than changing it. Run top for a live view of processes and system summaries. Look for patterns in CPU and memory use, and relate them to the affected workload, when the slowdown began, and recent system or application logs. The top manual describes a dynamic process view; a high CPU or memory figure is a clue to investigate, not proof of the cause.
As an Amazon Associate I earn from qualifying purchases.
In an interview, explain what you would compare over time and what evidence would narrow the cause—for example, a process consuming CPU during the slowdown versus a workload that is waiting on another resource. Avoid proposing a restart or killing a process before identifying what it is doing and what depends on it.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. A filesystem is full, but du does not explain the space reported by df. What next?
First distinguish filesystem capacity from the space accounted for in visible directory trees. df -h reports filesystem space in readable units; df -i reports inode availability. Use du to estimate usage under directories on the affected mount. GNU’s df documentation describes filesystem-level availability, while du estimates file and directory usage. These are different measurements, so their totals need not match.
#1 Best Overall
If the directory totals do not explain the filesystem usage, investigate open-but-deleted files, reserved space, and filesystem-specific accounting. lsof may help find processes holding deleted files open, although access restrictions and filesystem behavior can limit its results. Do not remove files based only on a large size; establish what owns them and whether a service still needs them.
3. A service will not start. How do you proceed?
On a systemd host, check the unit’s state and recent service-specific logs before attempting repeated restarts:
systemctl status <unit>
journalctl -u <unit> --since <time>Use the output to examine the exit status, unit configuration, dependencies, and application logs. A useful answer explains what each check can reveal and how that evidence would shape the next step. Correct configuration or another identified cause rather than making speculative edits.
Recommended Free Tools
systemctl and journalctl are systemd-oriented tools. On a host using a different init system or logging arrangement, use the equivalent service and log tools available there. See the systemctl manual and journalctl manual.
4. A device or driver is failing. What evidence do you gather?
Inspect kernel messages around the time of the failure with dmesg or the kernel journal, then check whether the device is present and whether its permissions and configuration are appropriate. Look for messages that match the device and timing; a single message does not establish causation. dmesg reads the kernel ring buffer, and access may be restricted by system policy. The dmesg manual documents the tool and its behavior.
5. A networked application cannot connect. How do you isolate the fault?
Separate the layers instead of treating “cannot connect” as one problem. Check interface and route state, test name resolution, establish whether the local service is listening on the expected address and port, and then test reachability to the remote target and port. Tools such as ss or lsof can help inspect listening sockets; lsof can also list Internet sockets, subject to permissions and system behavior. Consult the lsof manual for its scope and limitations.
Explain which result would point toward DNS, routing, local binding, or remote reachability. A failed ping alone does not prove that an application port is unreachable: the application’s target port and the network path need their own checks.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall6. The system appears to be under memory pressure. What do you check?
Observe process and system summaries, check memory and swap use, and review kernel messages for out-of-memory events. Look for a sustained pattern and connect it to workload and timing before terminating a process or changing a limit. top provides a dynamic view of processes and system summaries, while dmesg can show kernel messages; neither supplies a universal threshold at which every system is in trouble. Avoid presenting a single memory percentage as a diagnosis.
Best Value
- Comprehensive Preparation Made EASY: a smart system to get you mentally prepared for every interview question possible. Cards are categorized by evaluation criteria, topic, and difficulty levels by age group (teens, young adults, graduate students).
- Get INSIDE the Interviewer's Head: clever cards guide you through the secrets of answering questions confidently. Know the types of questions asked by interviewers from elite private high schools, universities, and graduate schools.
- Coaching Videos to Help You Brand Yourself to STAND OUT: includes expert advice providing examples of poor, okay, good, great, and memorable candidate responses.
- Build CONFIDENCE and COMMUNICATION SKILLS. It's not just about getting into your dream school or job. The card deck is designed to help you build the essential human skills to succeed in an AI-powered world.
- Perfect for conducting and practicing mock interviews anytime and anywhere while playing a card game. For students, parents, counselors, coaches, career services office, and recruitment professionals
7. A command fails with “permission denied.” What do you investigate?
Pin down the operation and exact path first. Check the effective user, ownership, permissions, and mount context, then compare with a known working case. If the cause is still opaque, strace can show the system calls a program makes and their arguments, return values, and signals. A trace can expose sensitive data, so limit what you capture and protect the output. See the strace manual.
8. The machine rebooted or crashed unexpectedly. What evidence matters?
Review the available journal records around the event, kernel messages, and boot history. Compare the last known change with relevant device or kernel errors. journalctl reads available journal entries, while dmesg examines the kernel ring buffer; they are different evidence sources. Logging persistence and access depend on configuration, so records may be incomplete. A careful answer states what the evidence supports and what remains unknown rather than claiming a specific cause from a missing or isolated log entry.
9. A mount is busy or a process is holding a file open. What do you do?
Use lsof to identify open files and associated processes, then confirm the mount and process context before choosing a cleanup or shutdown step. It can list regular files, directories, and network files, but permissions, blocked filesystem operations, and other system behavior can limit or delay results. Do not kill a process or unmount blindly: first determine what the process is doing and whether it is safe to stop.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
10. How do you explain your troubleshooting method in an interview?
Give the interviewer a sequence they can follow:
- Define the symptom and scope. State what is failing, who or what is affected, and when the problem began.
- Gather read-only evidence. Choose checks that answer a specific question, and explain what their outputs can and cannot show.
- Test one hypothesis at a time. Use each result to narrow the next check instead of changing several things at once.
- Preserve useful logs and context. Note relevant timing and changes so evidence is not lost during recovery.
- Make the smallest reversible correction supported by evidence. Describe the risk and why the change addresses the identified cause.
- Verify recovery. Check that the original symptom is gone and that the relevant service or workload behaves as expected.
This approach makes command choices meaningful: describe what a command should reveal and what different output would imply, rather than reciting a list of tools.
Further preparation
The Linux Foundation offers a Linux sysadmin interview-preparation resource with sample questions. For broader administration and troubleshooting background, InformIT lists Linux Administration Handbook, 2nd Edition; check the listing for current edition and availability information.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
