Three Things That Make a Good Technical Candidate

I have this conversation a lot with managers and colleagues in the industry.  It usually starts with, “what do you look for in a candidate when you’re doing an interview?”

Oftentimes, I’ll hear people talk about how their company only hires people with college degrees, or that they look for the number of certifications that the candidate has.  Usually when I hear these two things, the first thing I do is sigh.  While I will never beget someone for taking the time, effort, and financial expense to acquire a college or university degree, it also doesn’t necessarily give them the technical know-how to perform the kind of work we do.  Nor do certifications necessarily reflect technical knowledge.  Most certification exams that I’ve seen don’t actually test your practical knowledge of how something works, but rather your ability to memorize a book.

When I was going for my aircraft mechanic certifications, I was tested on three areas – General, Airframe, and PowerPlant.  Each area required three exams; an oral (spoken), practical, and written test.  Nine exams altogether.  The first thing we learned in mechanics’ school was that when we received these certifications, the only thing that we were really certified to do was learn how to do our job.  Until I gained enough experience performing tasks with someone inspecting my work each step of the way, there was no way I was certified to return an aircraft to service.

The same really goes in our industry.  I am sure as hell not going to turn some person fresh out of school loose on my production environment and simply trust them to do work.  So what really matters is their experience in the field, not the schooling.  But what really makes an exceptional candidate can be boiled down to three things – Critical Thinking Skills, Initiative, and Enthusiasm.

Critical Thinking Skills

When I’m interviewing a candidate for a position, I’m not barraging them with questions to troubleshoot some obscure issue.  That’s just uncomfortable for both you and the candidate.  What I do is give them a scenario and ask them to think the process through to the logical conclusion.

What’s the difference you may ask?

Troubleshooting scenarios usually consist of a lot of back and forth with the interviewer saying, “Okay, that didn’t work.  What next?” and then the candidate following up with next step questions.  It’s annoying and uncomfortable.  Often, this line of questioning devolves into a power struggle between the interviewer and candidate.  Stop it.

Instead, give them a problem scenario and ask them what they would do to investigate it.  Question them on why they chose the particular path they did.  Find out the reasoning behind it.  I want someone that can think about the task logically and follow the thread to it’s conclusion.  Ultimately, we are all going to run into issues that are going to be beyond our experience, and following a checklist isn’t going to help.  I need someone that will work methodically and logically and outside of the box.

Initiative

This is where the troubleshooting scenario also tends to fall short.  Oftentimes it follows a scripted, linear scenario.  This only proves that the person I’m interviewing is going to follow a scripted, linear process.  On top of being boring, it doesn’t help in those real-world scenarios that aren’t documented.

Don’t ask, about some obscure error code with the expectation that they’re going to blurt out what it means.  Ask them about situations that will show how they will go about finding the information.  A very basic question that usually weeds out a lot of candidates for me is, “If you’re looking through a co-workers code and you see a PowerShell command that you’re not familiar with, how would you find out what it does and how it works?”

I actually had a guy tell me that he would just run the code.  Awesome.  I want you looking at stuff in my production environment.

On the other side of the coin, I was once given a scenario question where I received an error in SCCM, and they asked me what log file I would look in to investigate.

Dude, really?  Do you even know how many log files are in an SCCM server depending on the role?

When I told him that I’d look up the error online first to nail down which log to look at, he wasn’t impressed with my answer, and I wasn’t really impressed with his response.

Enthusiasm (Willingness to Learn and Share)

Finally, enthusiasm.  You don’t want someone who’s going to come and and just do a job.  Our industry is changing every day and it affects every aspect of what we do.  There are going to be new technologies and challenges.  Our way of approaching problems is changing as we implement new things.  You want someone who’s always looking to the next thing, learns something new, and shares it with their team.

Ultimately, if they aren’t willing to learn something new and share it with others, they are going to slowly become a liability that holds the organization back from growing.  If they can’t go beyond a script to troubleshoot a problem, I can’t rely on that candidate to handle an issue that isn’t documented.  And finally, if the candidate can’t think logically, I can’t trust them to make the right decisions based on the available data to get the job done.