Submitted by aharper5 on
in
Forums
I just became a manager about 9 months ago. I also just discovered MT about a month ago and love it.
I manage a technical support team for a datacenter server company that's in a rapid growth period, so we're hiring multiple engineers each quarter. As a result, I've had a lot of practice interviewing these past 9 months. I love the process of developing behavioral interview questions and probing to determine decision-making abilities. I also like the idea of behavioral questions rather than test questions where you just go through a list of technical items and ask if they know each one.
What we have typically done at my company is use troubleshooting scenarios when interviewing candidates. We will provide them with a scenario of something being broken that's fairly generic and an industry standard and ask them to troubleshoot it. We use this to judge both their troubleshooting methodology as well as what technical commands, protocols, etc. they know and understand.
My question is how behavioral questions would be compared to scenario-based questions such as this. I'm going to be implementing behavioral interviewing questions where I have time in my phone screens, but I'm not sure if I should fix what isn't broken with our technical interviewing process.
I've been very impressed with the podcasts I've listened to (Trinity, Hiring, Performance Reviews, etc.) but would love some specifics for technical staff interviews.
Some examples to consider
Hi, if I were interviewing for specifically tech support, I would design some questions that get at behavior in past troubleshooting situations. For example, "tell me about a time when you needed to resolve a technical issue for a customer who interrupted frequently, like every 15 minutes, insisting on a status update or asking why it wasn't fixed yet." I would give an out - if they have never had to experience this, they need to tell you how they would approach it. But if you know you need seasoned tech support staff who have dealt with such a scenario before, then you want to know if they haven't. Other scenarios may be around decison making while troubleshooting: to escalate to their manager or a senior person (are they too quick to escalate, or too slow to make the right call), to involve a colleague vs keep trying to fix it themselves (what was more important, their ego or the customer), how did they communicate while troubleshooting (do they tune out everyone or do they realize they need to keep customers etc up to date on status). You can design questions about job-specific behaviors that show you how they approach a difficult problem, or something they have never seen before (they jump around, they use their gut rather than a proven methodology to eliminate more obvious problems). And I can imagine plenty of behavioral questions around how they work with a team (they are a lone wolf, they love to be the hero and solve the "big" problems but are too important to fix the small things). I've been on-call to troubleshoot tech problems for 12 of my past 15 years so that's the source for these questions. As well as hiring and training people who would be on call. I hope this helps with imagining behavioral questions that also get at how they handle real-life tech support issues. Jeanne
Thanks
Jeanne,
Thanks for replying. This definitely makes sense and has been my approach whenever possible. I think the hardest part is identifying the behaviors that I want to ask about. Escalating too quickly, working with the team, and researching a problem you've never seen are great to ask about. I also like what you said about giving them an "out" if they haven't experienced a scenario like this before. Often that will lead to almost walking through a scenario with them.
Example: Tell me about a time you've troubleshot Linux. You haven't before? Ok, where would you start if you needed to search for logs on Linux system?