Hiring support engineers: preparing the process
Thinking about preparing to initiate a plan to devise the blueprint to...
Now that you’re clear on what you’re looking for, it’s time to get out there and start recruiting! If you’re lucky and your job posting is good, you may even have some candidates already to start evaluating. Before we actually look at the specific interviews and technical exercises you want your candidates to go through, however, let’s spend a little time getting clear on what exactly you want to evaluate through this process.
First and foremost: degrees don’t matter. I know this attitude is becoming more and more prevalent, but it’s worth emphasizing. Degrees, and to a lesser extent, certifications, are not required to be a great support engineer! Now, to forestall the inevitable pushback, I will say that they can be useful as a marker of a certain base level of expertise. A degree in software engineering or information architecture or whatever is nothing to sneeze at, but all it tells you as a support leader is that this person has enough discipline and tenacity to make it through a degree program, and has attained a base skill level in a certain field. They are good indicators, but certainly not the only way to establish discipline, tenacity, and knowledge base. Same with industry certifications like AWS or other cloud certs—while this indicates the person has a knowledge base, what really matters is how they can put it to use. This leads us to…
Work experience
This is where it’s really important to look deeply at the candidate’s resume and/or LinkedIn. While doing so, ask yourself the following questions:
Have they held roles requiring (or establishing) expertise in the desired skillsets?
Have they specifically mentioned technologies or tasks that are key to succeeding in this role?
Do they have any customer-facing experience whatsoever? Perhaps a past stint as desktop support, or some time doing consulting, or anything that’s more customer-focused than sitting in front of a keyboard and hammering out code.
That last bullet point is really the key one. Even if this person ticks all the technical boxes, that’s only half the job. If they’ve shown zero interest in roles that require customer interaction throughout their career, proceed with caution. Dig deep in live interviews into why this person might be interested in working on your team.
Once you’ve done a first pass through your candidate pool, looking for folks that are a decent match to your ideal candidate profile, it’s time to start talking to them.
Before setting up the interview progression
When designing an interview process, you should first be clear on what exactly you’re hoping to learn about your candidates. Once you have that nailed down, try to figure out the shortest possible interview progression to make sure you’re learning what you need to know to make an informed decision. For a technical support role, you need to learn a few things:
Do they have enough of a background in your specific technical field to ensure onboarding won’t take an unacceptably long time?
Are they comfortable speaking to customers, and willing to do so regularly?
Are they able to communicate well both live and in written form?
Do they have that elusive troubleshooting mindset?
You’ll note that these bullet points fall roughly into two categories: technical and human-facing. The former can largely be established through technical exercises, but the latter are hard to suss out without speaking live. Those are the facts you’ll need to learn the old fashioned way: through talking directly to the candidate.
Unpacking some things
Before we move on to actually setting up your own interview progression, a few things from that previous list need a little expansion.
“Unacceptably long time” - what timeframe is acceptable for onboarding? In my experience you’ll need two months at a minimum to bring a reasonably technically prepared hire up to speed. But if you’re able to budget more time this broadens your horizons significantly when looking at candidates. If you are able to budget 6 months, for instance, you can start looking at more junior, or nontraditional, candidates who may need more ramp-up time.
Communication: think about how your support engineers will be interacting with customers and focus your efforts on the most common modality. If they’re spending all their time in email, don’t worry too much if their in-person demeanor needs polishing. Likewise, if they’re going to be doing phone support exclusively, don’t get too concerned about lackluster writing. That said, I wouldn’t suggest settling for anything below ‘acceptable,’ since almost every role is going to spend at least a little time both in written and in live conversation. Acceptable can be trained up to good, but it takes a lot of work to go from ‘bad’ to ‘okay’.
A troubleshooting mindset, or absence thereof, can be particularly tricky to infer throughout the typical interview process, so you may need to get creative. Maybe one of your technical exercises can be missing a step, or you may explicitly ask the candidate to find the root cause in a break-fix exercise.
Next time, the main event: an interview and exercise progression to find the answers to the above questions.
Thanks for reading Andy's Support Notes 💻💥📝!