In this video you’ll learn how to:
- Find a command that is not in your PATH.
- Find any file on a Linux system.
- Use the following commands: find, locate, type, which, grep, touch, updatedb, sudo, and ls.
In this video you’ll learn how to:
In this video you will learn:
Typically, companies hiring Linux and other IT professionals are resorting to a standard interview process. The whole operation is hacked together like Frankenstein’s monster. It’s complicated and stressful for all involved – and it’s what you’ve got to suffer through if you want a job in IT.
This article will help you get ready to master your next technical interview and keep your cool in the process. It’s kind of disappointing that an industry known for innovation is still mired in old-school, haphazard hiring practices, but it’s what we’re stuck with for now. So read on to learn how to prepare yourself mentally so you can show up as your best self, wow the hiring manager, and keep stress at bay – not just at the interview, but during the entire hiring process.
We’re jumping into this assuming that you’re at the beginning stages, but you’ve been in touch with the hiring manager at the company. You’ve sent in your resume, and now we’re moving on to your first direct interaction.
Once the company receives your resume and sees that you meet the minimum qualifications, they’re likely going to request a phone screening. This isn’t a technical interview. Instead, they just want to make sure you’re not crazy. It’ll last about 15 to 20 minutes, and the questions will be along the lines of:
Seriously, all they’re doing is seeing if you can speak without sounding like a psycho. Don’t ask stupid questions like “Do you have free beer on Fridays?” Don’t go super-deep, either. Just answer their questions in a coherent manner and you should be just fine.
There’s a chance they may ask you a few tech-oriented questions, but it’s going to be more along the lines of, “I see you’ve worked with Red Hat Enterprise Linux. Tell me about it.”
Really, they’re just weeding people out at this stage, so this is not where you have to super-wow anyone. Prove that you’re not totally crazy, prove that you’re more or less capable of talking to people and holding a job, and you’ll be fine.
If you want to prepare, just make sure you have good answers to the questions above, why you’re looking for a new job, and what you’ve been up to.
After the phone interview, you might have a technical phone interview, or be assigned a take-home project to check your technical chops.
The goal for the hiring manager is to get the number of interviews down to a reasonable level. After reading through everyone’s resumes and doing the first phone interview, they’ve gotten rid of about 90 percent of the clunkers, but there are still too many candidates to bring in for an interview. The tech screen will usually be pretty straightforward and simple questions to see whether or not you know what you said you know on your resume.
Typically, they’ll say, “I see on your resume you worked at X, Y, and Z.” Then you can say, “Yes, that’s where I did such-and-such and was in charge of this-and-that, and I did such-and-such as well.” Just give a basic overview. Don’t get too technical unless they ask for more detail.
If they do ask more questions, that’s a great sign. The deeper questions they ask, the better. At this point, it can be good to clarify the technical knowledge of the person you’re speaking to so you know if you’re talking to an actual technical person, or a receptionist who is just going down a checklist.
But be careful – it can be touchy. Do NOT assume that just because you’re talking to a woman, she isn’t technical. More than once, applicants have totally sunk their chances of getting hired because they were a total sexist jerk by assuming the person they were speaking to was a receptionist or administrative assistant, and not the platform engineer.
So if they don’t say, “Hey, this is Emily, I’m a senior platform engineer,” you can ask by phrasing it like, “I didn’t catch your position… what is your role?” Determine who you are talking to, no matter what they look or sound like. Be polite and you’ll be okay.
A take-home tech project will usually be a small programming project where you’ll need to do some scripting, or you’ll use some general purpose programming language of your choice to solve some problem. You might have to do some log analysis, for instance, and then you submit your code. (If you need help with shell scripting, check out my course on it here.)
To really show your best side, comment on your code and also provide a README, even if it’s just a couple of paragraphs long. It doesn’t have to be extensive or complicated. Just say something like, “This function does X. It takes this type of input and produces this type of output.”
If your project is timed and you don’t have time to write test cases or handle people putting in bad input, you can tell them how it will fail. You can say, “I didn’t have time to do this, but if your input is a string it’s going to fail this way.” Make sure to tell them what you weren’t able to test, otherwise they’re just going to assume that you didn’t know that you needed to test.
You can do the minimum, or you can use these projects to show that you’re a professional and you care about the quality of what you’re working on. (Hint: Don’t do the bare minimum.)
Whatever you hand in, be ready to talk through it afterwards. Don’t just copy the answer off the Internet. Be prepared to explain why you approached it the way you did. If you just copy the answer, you’re just going to look like a bigger jerk later when you get caught. Even if it’s too hard, just do your best and be upfront about it. The biggest thing is to be honest and act like a professional. You never know when you are going to run into someone again, so you don’t want to burn any bridges by lying yourself into a job.
After you make it past the first tech review, you’ll be invited in to meet people face-to-face. This is make-or-break time, and you need to be prepared. But don’t try to learn a totally new programming language or cram for your in-person meetings. You just aren’t going to be able to do it. You might think you’re pulling it off, but people who know are experienced in that area will know immediately that your knowledge is about an inch deep.
But while you don’t want to cram, you still can review things that you should know because of your previous roles.
Let’s say you’ve been using Puppet for configuration management for a couple years or you’ve done worked on Puppet at home, but you know they use Ansible for configuration management in the role you are applying for. I would definitely read over some Ansible documentation and look at a few examples, but your wheelhouse should be Puppet, so you better know Puppet. If they asked you to write an Ansible playbook, you can say, “I don’t really know how I would do it in Ansible, but I can show you how I do it in Puppet…” The main thing is to know what you SHOULD know and sound confident that you can learn what you need to learn for the new role.
Confidence is really key. It’s easy to stress out and get anxious. But remind yourself it’s not black or white. It’s rarely a case where you will totally pass or totally fail. If you don’t know something, just talk through it. You can be totally upfront and say, “I’m kind of stressed and I’m drawing a blank,” and then start breaking down the issue. Like, “OK, I don’t know how that config works, but I know that this has to happen so the request can go from A to B, and I know it’s going to talk to these three servers…” Then you’re giving them information and you’re showing them that even under duress you have a high level understanding and you’ve clearly worked with it before and you’re comfortable with it. That can be just as important is having gotten the answer “right.” And it can be even more important to show them your thought process.
Even the more technical aspects like whiteboarding or live coding are still just as much about seeing your thought process as they are seeing your familiarity with the tools of the language and your ability to get the right answer in a reasonable amount of time. After all, standing up in front of three or four people and working through a problem in real time on a whiteboard with a marker that probably doesn’t work… that’s not really a natural situation to put an engineer in. But even so, chances are you’re going to be in that situation, so be ready. And remember to talk through it and keep communicating.
It’s better to get it slightly wrong and be communicating about your thought process the whole time than it is to stand there silently for five minutes and then arrive at the right answer. After all, they’re not hiring you to solve that one specific problem on the board; they’re hiring you to solve a whole general class of problems that may or may not be like that. They want to know how you think, and the only way they’re going to know that is if you tell them what you’re thinking as you work through it.
At some point during your in-person interviews, you’re going to get a break or two. You might think, “They’re so nice, they’re letting me have some downtime,” or “Awesome, free lunch.” Don’t get fooled! You are STILL being evaluated during this time, often for personality or behavior.
There are plenty of ways for the interview to go wrong even when you’re not standing at the whiteboard. For instance, if you’re offered something to eat or drink, be polite about it. Say, “No thanks,” or “Yes please.” But don’t insult the company complaining about their drink choices or grumbling because they only have Diet Coke when you would much prefer Cherry Coke Zero.
As soon as you step out of your car and into the front door of the company, you’re being judged. You’re on stage, and you’re on until you walk out the door. If you’re sitting in the waiting room, don’t be doing anything out of the ordinary. People will notice if you stick your gum under your chair or eat all the good chocolates out of the bowl on the reception desk and leave the wrappers on the floor.
Don’t give them any excuse to think you’re anything but awesome. (Because you ARE awesome, right!)
Depending on how big the company is, you’ll likely meet with a director, VP, or even the COO, CEO, or CTO. This is the high level interview where you’re going to show them that you understand what the company does. If you don’t know before you get the interview, make sure you at least have a basic understanding of the company’s purpose before you start interviewing.
This is also a great way to show your interest in them. You can say, “I read that you do XYZ. Can you tell me how that works?” That gives you a chance to interview them a little bit, too.
Now that you know what to expect during the process, here are some additional tips to make sure you’re the most prepared and successful you can be:
Don’t be afraid to ask about the process. Sure, this article has given you a great outline, but it will vary a bit from company to company. Asking how the individual company does things will help you be better prepared. You can also ask when you can expect to hear back at each stage. It shows you’re interested in moving forward.
At least a quarter of the interview process should be you interviewing the company. Don’t be afraid to ask questions like:
If something’s important to you ask!
Word of warning: You don’t want to start out your first interview by asking how many vacation days you get, or if it’s okay that you come in at noon three times a week. But at some point in the process, this will become a negotiation, and you want answers to the questions that are important to you.
Don’t fall for the ping-pong table. Having a cool office is nice and all, but getting unlimited Monster drinks and access to bean bag chairs doesn’t make up for getting paid $10K under market.
Make sure you meet your boss. And by “boss,” that means the person who’s going to determine how much you’re going to get paid. If you don’t meet that person at some point in the interview process, that’s a warning sign. It doesn’t mean you should jump ship, but it is something worth asking about. Sometimes it can indicate that they’re in so much turmoil they don’t know who you’re going to report to. Sometimes it means things are in such flux that the org chart changes from one day to the next. And sometimes it just means it’s an oversight. But it’s worth asking about.
Prepare your questions for the interviewer. The worst thing you can do when someone asks you if you have any questions is to say, “No.” Instead, create a written list of questions about the company. Even if you have five or six interviews in a day, you can ask similar versions of the same question to each of your interviewers. Contrary to what you might think, asking questions actually shows your intelligence level.
• How much technical debt is there?
• How much freedom do you have to choose the solutions you implement?
• What’s the worst part of your job? (You probably won’t get a 100 percent truthful answer, but you’ll get a glimpse!)
Now that you know what to expect, hopefully you’ll remember that the most important part of the interview process is confidence. Knowing the “right” answer to any question is great, but it’s even more important to show that you’re an incredible, intelligent person who would be awesome to work with.
In this post I’m going to teach a quick, but valuable lesson on shell scripting.
First off, a shell script is simply a file that contains a series of Linux commands and shell statements. When a shell script is executed, it in turn executes the commands listed in the script. It starts at the top and executes the commands on each line, one line a time, until the end of the file.
By the way, the script’s filename doesn’t matter. You may be used to a different operating system where files have to have a specific file extension before they will be treated as an executable. (I’m talking about “.exe” files in Windows, for example.) That’s not the case with Linux shell scripts.
By convention, shell scripts end in “.sh”, but it is not a requirement. The following are all valid shell script names:
script42.sh do_or_do_not_there_is_no_try ThisIsSomeRescue
What IS important is that your shell script has execute permissions. (We’ll get to that in just a second.)
If you remember the advice my last post, it’s best to start with the end in mind. So, the goal for this shell script is to collect and display some basic information about the Linux system.
If you want to follow along, open up a terminal on a Linux system and create a new file named “sysinfo.sh”. If you have a favorite text editor, use that. If you don’t, I suggest you use nano as it’s simple to use and always displays help at the bottom of the screen.
$ nano sysinfo.sh
The very first line of every script you write should begin with “#!” followed by the path to an interpreter. We’re going to write a bash shell script, so we’ll use “#!/bin/bash”. If you were going to write a Python script this would be “#!/usr/bin/python”; a ruby script would be “#!/usr/bin/ruby” and so on.
One very common task you’ll perform in your shell scripts is displaying messages on the screen. To do this, use the echo command followed by whatever you want to display to the screen and enclose it in quotes. Like this:
#!/bin/bash echo "Starting the sysinfo script."
Now save your changes and exit your editor. If you’re using nano type Ctrl-X to exit, then type “Y” to save your changes, and finally press ENTER to write the changes to your script.
The next step is to add executable permissions to your script. You do this with the chmod command, which stands for “change mode”. There are different ways to add executable permissions to a file, but the simplest is chmod +x FILE_NAME.
$ chmod +x sysinfo.sh
Now you’re ready to execute your shell script. You do this by typing “./” followed by the script name:
You’ll see the text you supplied to the echo command displayed on your screen.
Now that you have a working shell script with the proper permissions, you can continue writing your script. Let’s add some commands that will display information about the Linux system.
First, display the current date and time when this information was collected.
#!/bin/bash echo "Starting the sysinfo script." date
Next, display the hostname of the system.
#!/bin/bash echo "Starting the sysinfo script." date hostname
Next, display the kernel release followed by the architecture. You’ll need to use the uname command to do this.
#!/bin/bash echo "Starting the sysinfo script." date hostname uname -r uname -m
Display the disk usage in a human readable format.
echo “Starting the sysinfo script.”
Finally, end the script by letting the user know that it’s done.
#!/bin/bash echo "Starting the sysinfo script." date hostname uname -r uname -m df -h echo "Stopping the sysinfo script."
It’s time to see what this little script does! Save your changes and execute your script.
Now you have a script that displays some basic information about the system you’re on. You could easily expand this to show information about the CPUs, memory, networking configuration and more.
If you would like to write even more in-depth and practical scripts, check out my Linux shell scripting course.
Hope to see you there,
From time to time one of my students will ask me to take a look at one of their shell scripts that they are having trouble with.
If you know anything about me at all, you know that I love three things. Linux, troubleshooting, and shell scripting. (Make that four things… teaching my love of Linux, troubleshooting and shell scripting!)
It’s almost irresistible to me so, so I’ll say “Sure, I’ll look at your script.”
Invariably they’ll send over a 100+ line shell script, riddled with syntax errors, inexplicable pieces of code, meaningless variable names and…. worst of all:
They don’t tell me what the shell script is supposed to do!
Why does this script exist?
What will it accomplish upon a successful run?
Can I at least get a simple comment at the top of the script justifying its existence?!? (Um, no.)
By the way, I’m not judging or blaming. We all start at the beginning. 😉 This is coming from a place of caring. I *want* people to write awesome shell scripts and I *love* helping them do it!
So, here’s my first piece of advice to any shell scripter:
START with the END in mind!
Well… sometimes people make assumptions about HOW to accomplish their larger goal. You may think you need to do A, B, C, D, E, F, G, and so on to get to Z, but in reality there may be a shortcut that takes you straight from A TO Z. (Shortcuts like bash builtins, predefined shell variables, Linux commands that you didn’t even know existed, etc.)
It’s the age-old case of not being able to see the forest for the trees and getting lost in the weeds. 🙂
You could easily end up with this:
When all you needed was this:
(Shameless plug: If you need help with learning the “shortcuts,” check out my latest project-based shell scripting class here.)
Another trap you can fall into is biting off more than you can chew. Once you have a goal in mind for your script, keep it focused on the essentials.
What MUST this script do?
If this script could only do one thing, what would that be?
What will get me 90% of the way to my goal with the least amount of effort?
Start there. Implement that first, then circle back around to the “nice-to-haves” or bigger goals for your script.
It’s way easier to light a room in your house than it is to illuminate the entire neighborhood.
Now you know where to start. In the next post, you’ll learn how to write a shell script.
P.S. Want to improve your shell scripting skills? Check this out.
Do you want to know where to find the answer to just about any Linux question you may ever have? Well…
All the answers are in the built-in man pages on a Linux system!
That’s probably not what you wanted to hear. 🙁
When you’re trying to figure something out or have a Linux question it can be annoying to get a reply like this:
“Just read the man page!”
It’s actually good advice, but it has one fatal flaw:
It assumes you know how to read a man page. Scratch that. It assumes you know how to understand and use what you read in a man page.
When you first start looking at man pages they might appear to contain a bunch of random punctuation. You might wonder…
To get the answers to all those questions and more, watch the video on this page. It will have you reading man pages like an old pro. You’ll finally understand all those man page hieroglyphics and you’ll never feel lost again. 😉
If you’ve ever seen anything in a man page that you didn’t understand, this will definitely help you out.