Technical skills every software engineer interviewer should have

Hiring for Tech
January 11, 2021

Green text going down the screen on a black background, like in the 1999 movie The Matrix.

More than even the candidate, the interviewer has a higher technical bar to meet. Photo by Markus Spiske on Unsplash

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:

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.

interviewers