Interviews can be stressful, especially when technical problems come up unexpectedly. Whether it’s a system crash or network failure, how you handle these issues can affect your chances of getting the job.
Employers want to see more than just what you know during this tough situation. They want to see how you handle things when things go wrong.
Having some pretty good troubleshooting skills comes in handy. You will stand out from other applicants because you can keep calm and think through problems logically.
What is Troubleshooting?
Let’s start by discussing some troubleshooting procedures. So, what exactly is troubleshooting? Troubleshooting is about encountering a problem, gathering information about it, analysing it, and finally fixing it.
Two Approaches to Troubleshooting
There are two ways to fix problems: the quick-fix method and the consistent methodology. For simple problems, a quick fix might work, but for more complicated ones, you need to follow a plan. The scientific method is used in this blog.
The Scientific Method for Troubleshooting
The scientific approach to troubleshooting involves five essential steps. These are:
Step 1: Defining the Issue
The first step is to define the issue clearly. Instead of saying, “The FTP server isn’t working,” be specific: “I cannot connect to an FTP server from my machine.”
Specificity is key here because vague problem definitions won’t lead to effective solutions. Often, reported issues are just symptoms of another underlying problem.
You need to ask the right questions to get this picture clear, as right questioning is a skill.
Step 2: Gathering Information
Next, get useful information. For instance, if you’re working with Red Hat, looking at the log files for your service with systemctl status can help you learn more.
Also, remember that you shouldn’t get too much information. You should only get enough to figure out what might be wrong.
During interviews, when explaining how you gathered information, make sure to articulate your thought process clearly. Employers are looking for a logical flow in your problem-solving skills.
Step 3: Form a Hypothesis
Once you have enough information, form a hypothesis, or an educated guess, about what might be causing the problem. Think of it as identifying a likely culprit. For instance, if you suspect SELinux is causing the issue, investigate and test that hypothesis.
Step 4: Test the Hypothesis
Now it’s time to test. If your hypothesis involves a firewall issue, investigate it by testing the system with different configurations. Once you have tested and validated your hypothesis, you can attempt to fix the problem.
Step 5: Apply the Fix
After testing, put your fix in place. Remember, though, that troubleshooting can happen more than once. It’s possible that your first guess was wrong if the first fix doesn’t work.
You’ll have to start over, change the question, get more information, and come up with a new hypothesis.
Real-World Troubleshooting: An SSH Example
I will show you how to use this method to fix problems in the real world. Someone is having trouble using SSH to log in to a server.
To begin this troubleshooting, we will first describe the issue. The problem is that Linda, the user, can’t log in from a different server. This gives us a clear problem to describe: Linda can’t use SSH to log in.
The SSH is just an example. It’s not a recommendation.
Reproducing the Issue
When reproducing the problem, we observe that SSH is operational because it responds to the login attempt. However, when the password is entered, the login is denied.
During interviews, if given a similar scenario, explain how you would reproduce the issue, making sure to walk the interviewer through your assumptions and testing. This shows a methodical, thorough approach.
Gathering More Information
Right now, we need to find out more. To see if SSH works for other accounts, we can log in as Root first. It’s likely the user account, not SSH itself, that’s broken if Root can log in.
As a security practice, the Root user needs to deal carefully with any given system. Therefore, the example assumes we have this authorisation.
Analysing Logs and Forming a Hypothesis
By analysing the logs, we notice a failed password attempt for Linda. Based on this, we hypothesise that there is something wrong with her password. To test this, we reset Linda’s password and attempt to log in again.
If this was during an interview, explain why this hypothesis makes sense based on the information gathered. The ability to justify your choices shows the depth of your understanding, which interviewers appreciate.
Sample log check:
$ sudo tail -f /var/log/secure
Sample output:
Resetting the password:
Testing and Fixing
After resetting the password, Linda is now able to connect. However, she is immediately kicked out. This indicates that while the password issue was part of the problem, another underlying issue still exists.
Sample login attempt after resetting the password:
Starting Over and Gathering More Information
We go back to gather more information. Checking the user account settings reveals that Linda’s shell is set to bin/false, which prevents her from logging in. We change her shell to bin/bash and test the login again.
Checking Linda’s shell:
Changing the shell:
sudo usermod -s /bin/bash linda
Verifying the change:
Final Fix
After applying this fix, Linda can now successfully log in via SSH.
Closing Thought
The above approach is helpful when you are in the middle of a situation and trying to solve the problem. If you try to follow this approach and discuss it during your troubleshooting interviews, this will show that you have an approach to tackling problems.
You may disagree with this approach and say you already do this or even have a better, nothing new for you, which is perfectly fine. This may help those who are just a starter looking for some approaches to troubleshooting issues or want to know how to tackle them during tech interviews, especially with troubleshooting situations. These approaches are gathered from various sources and presented in the blog. Thanks to Sander van for some references.
If you liked this article and have feedback, feel free to connect me!
