Technical skills every software engineer interviewer should have
There’s a lot of discussion about technical skills candidates need to have, like algorithms, systems design, technical communication. But I actually think the interviewer is the one with the greater responsibility.
Think of it this way. A candidate needs to demonstrate they are capable of the job they are being hired for. That means they need to have the technical skills they will use on the job and, in an ideal world, that should be enough. But the interviewer’s job is to assess if the candidate can succeed on the job, which is not an assessment that happens regularly with their coworkers. The interviewer has to perform this assessment for a variety of candidates with different skill sets and backgrounds.
Familiarity with different technologies
Candidates come from diverse backgrounds. If you hire a capable engineer, you will train them on your particular tech stack, but that will take time. In the hour or so you have to evaluate an experienced engineer, the most valuable data point you can consider is how they perform using the tools they are familiar with. After all, that’s the way they’ll work on your team in the long term.
So, it’s up to you, as the interviewer, to accommodate different backgrounds:
- An obvious one is programming language. Two weeks into the job, the candidate will have re-familiarized themselves enough with Java to be productive. But for the last few years, they’ve been working in Python, and they’ll be best able to show the command of Object Oriented patterns and problem solving using Python. Your job is to have enough familiarity with common programming languages to understand the code they’re writing.
- Familiarize yourself with different tools in the same space. Your company uses Kafka, but the candidate is more familiar with RabbitMQ. If you understand the landscape of message queues, you can better evaluate if the candidate knows how a message queue fits into a bigger system. The more you know about RabbitMQ, the better you can assess if they understand the trade-offs of RabbitMQ, and therefore how well they’ll understand why your company chose Kafka. Finally, by understanding the technologies on the candidate’s resume, you’ll know what their area of expertise is, even if you’ve never personally used those technologies.
- Lastly, recognize different approaches to the same problem. Different businesses make different trade-offs. Interview problems often have different solutions. Just because the candidate approaches a problem differently than you doesn’t disqualify them. What matters is they can justify their choices, and that you can intelligently understand those justifications.
Only by having a strong grasp of different technologies can you engage candidates on their own areas of expertise. That is, after all, where you’ll get the most useful signals about their technical ability.
Quick comprehension
Think about how you review code. You have to comprehend the code, verify it solves the problem it claims to solve and find any issues with the implementation that automated tooling wasn’t able to find. Evaluating a candidate’s code during an interview is like reviewing code, but faster paced. And that makes sense: if the candidate is writing code under pressure, you have to review code under pressure.
The consequence of this is you, as an interviewer, have to be really good at reviewing code. You, of course, need to know the candidate solved the problem correctly, even if they used an approach or coding style you didn’t anticipate. If they didn’t solve the problem correctly, you have to find the error quickly so you can help them get back on track, or simply to note how close they got to the solution. This is especially important if the clock is running out.
I still believe an experienced candidate should not have to prepare for an interview, because the goal of the interview is to see how they would perform on the job, not how they perform in the interview itself. To make this possible, it’s crucially important for interviewers to step up their game and be exceptional at conducting interviews. And that means being exceptional technically.
At the end of the day, a candidate has one set of strengths. But you have to know enough to recognize all the combinations of strengths different candidates bring to the table.
This article was originally published on the Hiring For Tech website. If you want to read more content from me, please subscribe either by email or on LinkedIn. If you have any thoughts about my content, comment below. And don't forget to follow me for more content!