Hiring support engineers: the interview process
FINALLY
The interview process
To recap what we talked about last week, you should already have spent some time figuring out what exactly you’re trying to learn about your candidates through the hiring process. Typically that’ll be things like:
Can they technically do the job?
Do they have sufficient people skills to interact with customers regularly? Do they even want to do this?
Are they going to thrive in a troubleshooting environment?
Once you’re clear on specifically what you’re trying to establish, it should be a lot easier to look at an existing hiring process to see what works and what doesn’t work, or to build a new one.
The hiring process is going to be one or more of each of the following types of interactions. Each one of these could probably be a post in its own right—and, knowing me, they will be at some point—but for now I’ll confine myself to the basics.
Live interviews: this is where you really get to know the candidate by speaking to them live, either in person, on the phone, or via video chat. You should have at a minimum two interviews: one with the hiring manager and one with a peer, if any are available. You’ll get different insights from both, though it’s important that everyone has been trained beforehand in doing interviews and knowing which topics are appropriate to discuss.
Technical exercises: here the candidate can show you what they really know by completing specific tasks you set for them. Devise something relatively straightforward to put the candidate’s stated experience to the test. The goals for this kind of exercise are that it be a) easy and b) asynchronous—the candidate can complete it on their own time and not spend too much time on it. If you find your candidates taking more than an hour or two, that’s too long. And by no means should these projects involve doing actual work for you. Instead, use contrived mini-projects that exercise the same skillsets. In some cases a live exercise with someone on your team makes sense, but those should be even shorter: no more than half an hour, ideally piggy-backed onto an interview session.
Recruiter screenings/checkins: the glue of the process, the recruiter or equivalent in your organization will keep the hiring schedule moving, checking in regularly with the candidate to keep them prepared and engaged as they work their way though the process.
General considerations
Beyond the specifics above, here are a few general points to keep in mind when building up your own support process:
Length: the trend in the tech industry has been to move to shorter and shorter interview cycles, with the thought that it’s better to decide quickly than to risk taking too long and either annoying the candidate or losing them to a faster-moving competitor. I applaud this trend, but unfortunately the specific requirements of a technical support role typically require more steps than is currently in vogue. That said, cut the process as short as you can manage, while still gathering your required data points. Your candidates (and recruiter) will thank you.
Diversity of viewpoints: make sure yours isn’t the only voice that the candidate hears. They should be speaking with the hiring manager and a peer at a minimum, and perhaps a group discussion with several folks if you can align schedules. This not only lets them meet more of their prospective colleagues, but gives you more sets of eyes on your side that can highlight strengths or concerns that you might not have noticed yourself.
Collaboration: don’t just take and ignore feedback from other people, particularly your team members, involved in the process. Pay attention, ask qualifying questions, and listen to the answers you receive. Though in the end the final decision to hire or not will probably come down to you, it’s worth your time to build consensus first. This will not just be better for the new hire who can come into a team who all agree they’re the right choice, but will also build trust on your team that their viewpoints are heard and respected.
My process
Every organization is going to have different specific needs for its customer engineers, and therefore a different hiring process. You shouldn’t read and adopt any interview progressions you see other organizations use, including this one, without thinking carefully about how to to customize it for your own needs. That said, this is the most recent version of my own hiring process for experienced support engineers. It’s unavoidably a bit long but has consistently resulted in great hires.
Initial screening. This can be either by the hiring manager or, if you have in-house recruiters, the recruiter assigned to the role. This is to get basic questions out of the way, verify interest, and do limited screening to ensure the person’s experience appears to match their resume or LinkedIn.
Tech screening. In my last role we did what we called the ‘Linux Escape Room’, a virtual machine shared with the candidate that is broken several ways both obvious and subtle. The candidate spent more or less an hour fixing it and writing up a support-ticket-style response, then the team and I reviewed the email and session recording. Our criteria were speed, completeness, and fluency, as we were screening for people who could do command-line troubleshooting under pressure.
Once it was clear the candidate had a base aptitude with tech and troubleshooting, the next step was a live session with a senior support engineer to look at how they handle customer interactions by critiquing old support tickets from our system. The candidate would suggest ways our engineer could have handled the ticket better, and we’d get a feel for how the candidate would interact with customers in an email-based support environment, which was our bread and butter.
At this point the hiring manager would step in for a conversation to get a personal feel for the candidate’s experience and skillset. When I conducted these interviews, I’d tend to steer clear of specific technical topics unless previous steps have flagged concerns or areas to dig deeper. Instead I’d do story time (i.e. the dreaded behavioral questions that start with ‘tell me about…’) to try to establish the candidate’s breadth of expertise, resilience, and general approach to problem solving. I was also sure to leave time to answer any other questions that may have come up. At the end, I previewed the final major step:
Cloud exercise and team interview. The candidate spent an hour or two setting up a cloud environment to complete a specific simple task (setting up a one-page webpage) in as convoluted a way as they were comfortable with. Then they presented and discussed their solution with their prospective peers, without the hiring manager in attendance. This let them discuss the role with peers, show off their cloud and orchestration skills, and display their comfort with presenting and taking questions in front of an audience of strangers. After this session the individual team members provided feedback to the hiring manager and the team got together to discuss next steps.
Once you get a candidate to this point in your process, you should have a good understanding whether you want to hire this person. It’s time to close them, or gently break up. In either case, the recruiter has one more call with the candidate to either wrap up the process or give them a final pitch to join. For particularly strong candidates, or if the candidate asks for it, the hiring manager or her own manager may step in to chat with the candidate as well.
The actual mechanics of making an offer, expressing benefits, and so on are beyond the scope of this discussion, but consult with your friendly local recruiter or HR person to learn more.
Next time: onboarding!
Thanks for reading Andy's Support Notes 💻💥📝!