How to Prepare for (and Ace) Your Next Technical Interview

Typically, companies that hire Linux and other IT professionals use a standard interview process. However, 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 rather 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.

The Phone Screen Interview

Once the company receives your resume and sees that you meet the minimum qualifications, they’re likely going to request a phone screen. 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:

  • Why are you looking for a new job?
  • Why did you apply here?
  • What about the job description caught your eye?
  • What kind of work have you been doing?

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.

The First Technical Screen

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 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.

The First In-Person Interview

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 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 of 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 certainly 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 completely 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 such as whiteboarding or live coding are still just as much about seeing your thought process as they are about 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 while working through a problem in real-time on a whiteboard with a marker that probably doesn’t work is not a natural situation to put an engineer in. 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 while communicating 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.

Taking Breaks During the Interview

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 be 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 by 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 do 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 are anything but awesome.  (Because you ARE awesome, right!)

Being Interviewed by an Executive

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.

Technical Interviewing Tips

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:

  • Can I see where I’m going to work?
  • Can I meet some of the people that I’m going to work with?
  • What is the standard vacation policy?

If something’s important to you ask!

Word of warning: You don’t want to start 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!)

Confidently Tackle Your Next IT Interview!

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.

Download My “Interview Prep” Cheat Sheet
When you enter your email address below, you’ll be sent a PDF with 11 of the most commonly asked question in an interview plus tips for how to answer each one.
We respect your privacy.