The Interview Process - Questions for the In-person interview

So what type of questions should you ask? Well, the first thing to keep in mind is the role that this person is going to fill. This is going dictate a certain minimum level of technical competency, and is something that your screening questions should have targeted already. After that you should have goals or areas-of-interest that you’re trying to satisfy. These should be designed to help you determine the “fit” of a candidate to your need. Technical competency questions are more measurable and objective than the fit/areas-of-interest questions, but you’ll weave these together to identify a candidate to hire.

Since we’ve been talking mostly about a “Server Analyst” or “Sysadmin” type of position in this series of posts, I’ll focus on that in my example.

Ok… but, what to ask?

“Tell me about yourself”… This one is a good (if obvious) first question because it marks the transition from making the candidate comfortable, to getting to know them as a potential employee. Some candidates will ask for some clarification, others will start telling you about their current job, and still others will tell you about something in no way relevant to the task at hand. So it’s actually an interesting tell right off the bat.

But only let that last one go so far… make sure you get them on track quickly with… “Tell me about your current employer, and your role in the organization.” That’s really what I wanted when I asked the first question, so you might consider stringing them into one. The first part of this is finding out what their employer does. If it’s a tech-company, or something tech-like, then you’ll get some context. If it’s a large corporation, then you’ll know to illicit some feedback on other areas that will determine the breadth of their experience. Finally, if they work in a small organization you’ll know that you need to focus on the day-to-day technical aspects of what the job will entail –so you have some idea if they are technically capable of the position. The second part of that question is about their role.

What’s their role again? Are you sure?

Server Analyst, Systems Engineer, Network Engineer, Network Administrator, IT Manager… and so on are used so interchangeably in this profession that I never really know what someone does until I meet them and talk to them about their role. Make sure if you want a “server analyst”, you’re getting the type of server analyst that you’d expect. So figure out the context…

For context, I start asking for some numbers… “How many servers are you directly responsible for?”, “How many users?”, “how many customers/clients”… numbers don’t necessarily tell you a whole lot, but it’s enough to figure-out if they’ve been forced to rely on some type of automation, or if they’re just dabbling as a server analyst. Let me explain… if someone tells me they’re responsible for a 200 user environment, with 4 servers, I know I’m going to have to illicit some more information to figure out if the their role is really that of a “server analyst”, or if they’re a “desktop support” person who does some server stuff when necessary. On the other hand, if they tell me they’re a Citrix Metaframe admin, with a 30-server farm, then I’m going to ask an entirely different set of questions. In either case, I’ll proceed to figure out if they have they experience in the areas-of-interest that I’m looking for. Personally, I usually need someone with good customer relationship skills, someone capable of juggling multiple priorities (often technical), while maintaining an excellent attitude, and always being customer-focused and driven. In the 200-user environment example, this might drive a whole other line of questioning… “So you’re responsible for 4 servers? What do they run?” Oh, you run Exchange? What version, and at what service pack? How many Exchange databases – if multiple, what drove you to use more than 1? What tool(s) would you run to troubleshoot a problem with your priv.mdb file?”… “So you’ve used eseutil before – tell me what you did with it”? I’m not looking for someone who knows the command-line flags of a random tool, I'm interested in their approach. I don’t want someone whose only answer is that they look stuff up in newsgroups, or in a KB article either - but it's okay to use resrouces to find information.

So in the above, I was trying to get a picture for what their job looks like. To generalize – are they Enterprise, or SMB? And beyond that, I tried to illicit some technical details about their environment. I was able to validate that they ran Exchange, and were up-to-date on the SP level, and if they’ve ever had to troubleshoot an Exchange server that was down. Now, depending on your need, you might want to get some more detail. Maybe ask about what other services are being provided by the Exchange server – find out if the placement of the Exchange databases makes sense in terms of the storage configuration and server utilization. Are they using a SAN to host the Exchange databases? If so, what challenges did they run into with making this work reliably. And so on… if you’re asking technical questions, you probably want to avoid getting too deep in an area that you have no experience in - as any technical person knows, it’s pretty easy to spot someone trying to fake knowledge or experience. So with that in mind, you’re going to want to ask a series of questions that are designed to give the candidate an opportunity to explain something to you as if you were a novice. There are a couple of schools of thought here – either pick something that you know a lot about so that you can coach the candidate and illicit the information you’re looking for, or pick something that you have no background on. I usually do both, but focus on the later. This will let you can focus on watching the candidate explain something to you, and to determine if their explanation makes sense. Ask them to explain the details, and why things are they way they are. It’s an excellent opportunity for you to A) learn something new, and B) figure out if the candidate can explain something to a novice. This will help you learn about their attitude, and their approach to working with clients.

Why is the sky blue? (Or, how to use open-ended questions)

This can be a really good tool for figuring out if a candidate is doing root cause analysis, or just treating symptoms, as well as putting them under pressure and letting a scenario play out that you might have come across in the real world. Be careful with this though, because if you haven’t carefully thought out the branches that this question can take, you might be setting a candidate up for failure based on the bias that you introduce. Questions like… “Tell me how you would troubleshoot a complaint of slow internet access” are good because they can tell you a lot about a candidate. Now, I’m not going to look at the branches this particular question might take here, but expect the candidate to talk about name resolution, bandwidth, user counts, IDS/IPS, HIDS, antivirus, networking infrastructure, and so on. Keep in mind that you’re not necessarily evaluating a candidate’s ability to figure out what’s going on at the packet-level (though you might be), what you’re really interested in is how the candidate responds to the pressure of an open-ended question. Do they freeze-up, or get noticeably stressed out? Do they get frustrated at not being able to get to the root-cause? Are they comfortable with telling you that they don’t know at some point? And do they offer a reasonable path-forward (i.e. get the Network Engineering tem involved; call Microsoft PSS if relevant, etc.)? Get them to tell you about why the sky is blue, and you’ll learn a lot about them.

Managing Expectations

This helps you learn about how the candidate interfaces with client, and if they can juggle multiple priorities, while maintaining a positive attitude. When it comes to clients/customers, everything is a priority because they’re the ones that pay the bills. So it’s important that they can demonstrate the ability to manage client-expectations while still balancing other commitments and responsibilities. The way I usually do this is by giving them a scenario... something like this… “Client A needs an inventory of IT assets for an auditor by tomorrow”… while “Client B’s CRM application is down”, and you don’t have any other staffing resources to help you manage this. Tell me how you would handle this scenario? Now, admittedly scenarios like this are only going to tell you so much about how they handle real-life situations… but it’s better than nothing, and gives them an idea of the type of issue they’ll be up against. The candidate should start by asking you questions something like this... “What’s the SLA for those items?” “Do we have a knowledge base on the CRM app, or a vendor relationship that we can leverage on the CRM app?” “Do we have an existing asset inventory that I can send, or is it something we can generate?”. Coach candidate, and get him/her direction as they need. Then have them explain why they’re doing what they’re doing. It doesn’t really matter which one they provide service to first, or if they have a plan to get both issues resolved – just that they had a plan that had been reasoned out

The Road Ahead

I always ask about tomorrow – industry trends, changes in technology, changes in perceptions... It gives the candidate an opportunity to show a passion for the field, and for the future. And it gives you a window into how they see the world. Ask them where they see the IT business in 5 years. Or better yet, how they see the role of the IT service provider changing – assuming they already have some exposure in this area. This flows nicely into questions about where they see themselves from a technical standpoint 5-years down the line… which flows into questions about like… “Technology constantly changes – how do you keep up”?

Summary

I hope this post proves helpful, and that it demonstrates that the interview process should be a conversation – there’s an ebb and flow to it. It’s not a list of 10 questions that you can check off of a list. And it’s not just softball questions about what the candidate thinks about certain things. Please don’t consider this to be a be-all-end all list of questions, rather see it as a list of ideas for managing the conversation, and getting useful information from the candidate. In the end, it’s important to keep in mind that you’re really looking for a “good fit”. Assuming the candidate meets a base-level of technical competency, focus on their attitude, pay attention to how the talk - if they’re able to have a conversation, and if you think they’ll be able to interface well with your clients, and will represent your organization well.