Welcome Back!

This is the second blog post in my series called Interviewing for an IT Job. If you have not read the series announcement and my previous post, please do so.


Index of Related Posts:
1. Interviewing for an IT Job
2. What You Need to Know When Interviewing For a Job in IT
3. What to Expect When Going Through the Technical Interview
4. What You Should Know about Headhunters and Recruiters
5. Tips for Networking Success
6. 5 Tips for Successful Webcam Interviews
7. The Basics of Troubleshooting – Part 1 – Ping
8. The Basics of Troubleshooting – Part 2 – Traceroute
9. The Basics of Troubleshooting – Part 3 – Firewalls
10. The Basics of Troubleshooting – Part 4 – NAT
11. The Basics of Troubleshooting – Part 5 – PAT
12. The Basics of Troubleshooting – Part 6 – 1:1 NAT
13. The Basics of Troubleshooting – Part 7 – Port Forwarding

As I mentioned in my initial post, I have interviewed many candidates over the years.   Most of them were interviewed for the IT help desk, data center operations and field technician positions.

Obviously I can’t cover all the facets of a technical interview, especially because these interviews can vary tremendously from one specialty to another and from one industry to another.  For example, an interview for a web developer’s position will be quite different from an interview for a help desk position.

However, I can give you an insight and some tips on how a hiring manager may evaluate you on this phase of the interviewing process.

Let’s Get Started!

Listen, Think, Answer

Throughout the interview listen carefully to the questions, and answer them calmly.  Sometimes you may be asked tricky questions to test your understanding of a certain subject. If you are not sure, do not make up any answers.  It is OK to say you don’t know the answer; however it is not OK to lie. This is the worst time to make up answers.

Also, do not stretch the truth.  I once interviewed a candidate who claimed to have configured and deployed Cisco routers.  It took me only a couple of questions to find out that he did not even know what a rollover cable was.  At the end, I found out that he provisioned Cisco routers (provisioned, not configured) using a configuration management system that was completely automated.  I hired this guy, obviously not as a Cisco engineer, but because I saw in him the potential to work on other IT supporting roles.

What to Expect When Going Through the Technical Interview

Technical interviews vary tremendously in format.  Most of the interviews I’ve attended both as a hiring manager or a candidate followed a basic format:

First, a manager or senior engineer will review your resume and ask you questions about:

  •  Your previous jobs
  • The skills and technologies you’ve listed on your resume
  • Projects you have worked on
  • Certifications and education

Most likely, after you have talked to the hiring manager, you will be talking to potential co-workers and technical staff, and it could be a one-on-one or several people interviewing you at once.  Based on my experience, the latter is more common.

Once the basics are covered, then you will probably be asked to demonstrate your knowledge.  For a support position, most likely you will be required to demonstrate your troubleshooting skills and how you would handle a support call. Developers, for instance, may be asked to talk about patterns, best practices, source code management, development tools, programming languages, etc.

As you can imagine the questions will be specific to the technical specialty and job position you are interviewing for.

Sometimes you are required to go to a white board to demonstrate your knowledge and problem solving skills. At other times you will encounter a written test and maybe even a hands-on test (e.g. troubleshoot a PC).

Do Your Best To Keep Your Cool.  It’s Not Personal.

Technical interviews tend to be intense. Especially for support positions, the interviewer(s) tend to make the process a bit uncomfortable for the candidate with the objective to measure how the candidate manages stressful situations.

Let me warn you about some interviewing styles.

Companies like Google have a whole different philosophy on how to interview a candidate.  Check out this link: Hangout on Air: Candidate coaching session – Tech interviewing.  I am not endorsing Google’s interviewing methodology, but I can understand why they do so.

Now, there are other companies that think they are like Google and, pardon my honesty, have a ludicrous approach to measuring the candidates potential.

Let me explain…

Several years ago, I walked out during an interview at a big tech company in Silicon Valley. This company was publicly traded and their stock was hot in the market.  Their engineers were just full of it. Besides being very disrespectful during the interview, their “prima donna” attitude was pathetic.  After thirty minutes of non-sense questions, I just could not take it anymore.  I was sure that I did not want to work with those Bozos.  So, I thanked them and left the room.

A good friend of mine described a similar experience when he interviewed at a large telecom company, and he walked away when one of the engineers at the table threw a paper ball at him to see if he could handle pressure. Was that necessary? No.

How I Conduct My Interviews

After all these years, I am proud to say I have an excellent track record for new hires.  For the past eighteen years or so, only one candidate fooled me [really good] and he turned out to be a total weasel.  That’s OK, I learned from that bad experience.

Now, if I were to interview you, I would try to learn the following from you:

  •  Do you have the minimum technical knowledge for the position I am hiring?
  • Do you want to learn? Are you interested in self-development? Do you require formal classroom training?
  • How do you react to changes? How do you deal with technological changes?
  • Do you take the initiative to solve a problem?
  • Do you take ownership of a problem?
  • Do you take accountability for your mistakes?
  • How do you resolve conflicts?
  • Can you handle pressure and deadlines?
  • Do you like to share your knowledge and mentor others?
  • What is your personality type?
  • What motivates you?
  • What do you enjoy working on?
  • What do you avoid working on?

I always pay attention to the candidate’s demeanor and to the non-verbal communication while he or she answers my questions.  It’s fairly easy to identify whether someone is not being truthful or is unsure about the answers.  That’s why I always say that it’s OK to tell me you don’t know the answer.

Then I like to move to the technical part of the interview.  Using the same approach, I start asking questions about the skills listed on the resume.

For example, if you’ve mentioned that you have worked with servers or desktop PCs, I am going to ask you if you have take them apart, and if you know what the controllers do.  I am interested in knowing how involved you were in installing and configuring the servers, whether you know what a RAID array is, or what SATA or SAS means.

I will dig deep into these subjects with the main objective of understanding what you have been exposed to, whether you have hands on experience or you have not had the opportunity to work on that type of hardware at all.

Once I have learned about your skills and experiences, I will move to the part I enjoy the most, the troubleshooting test.

Let Me Pick Your Brain

Let me clarify why I enjoy this test so much.  This interaction with the candidate, which usually takes 10 to 15 minutes, helps me be certain that not only does he have the very basic skills I require for any support position, but also that I can understand how he approaches a problem, dissects it, and uses his knowledge and skills to walk me through the troubleshooting steps.

Honestly, this is when lots of candidates get nervous.  Some are very well prepared and others have never done any troubleshooting.  None of my candidates have cried on this test yet, but several sweated bullets.  Joking aside…

You need to understand that to me even if you know how to write code, manage servers, install software or know lots about a certain technology, but don’t know how to effectively troubleshoot a problem, using logical and analytical thinking, you may not be suited for the position I am hiring for.

You are not doomed if you are not good at troubleshooting (yet).  But you should definitely invest your time in learning the technologies, techniques and troubleshooting methodologies that are related to your expertise.

For example, if you are a software developer, you should learn how to effectively trap errors and debug your code.  If you work with servers and networking, you should learn how to traceroute or ping a device.

Keep in mind that you will get better at troubleshooting with time and hands-on experience but, unfortunately, not all jobs will give you the opportunity to sharpen your troubleshooting skills.

I am here to help you, and I want to share some tips and resources with you that may help you improve your troubleshooting skills.

What’s next?

Next week, I am going to walk you through one of the troubleshooting tests I like give to my candidates.  Furthermore, I am going to help you in learning the basics of my methodology, so you can be up and running quickly.  In the following posts we will get into the details.

I want to thank all those who sent me their comments and feedback. Join me!