Three common interview practices I wish to see less of

I'm not a fan of some common practices in technical interviews for software engineer candidates. At first, I thought it was just a personal pet peeve, but I've reached a point where I believe I can sensibly defend my disapproval. This blog post is my attempt to do so.

Some of my opinions might be controversial and you may not agree with them all. That's totally okay. At least I hope they are thought-provoking enough to make you reconsider the hiring practices your team or company currently has and start iterating on the existing interview format.

Here is a list of three common interview practices I would like to see less of:

I only talk about interview processes that are designed to hire rank-and-file, general software engineers as opposed to highly specialized roles such as Site Reliability Engineer or Research Engineer. You might have a totally different hiring process for those roles.

Ask candidates to explain concepts (as the primary way to test their knowledge)#

Many interviewers like to ask candidates to explain programming concepts to them. In web development, some of the most common questions would be “describe what closure is”, “describe what Event Loop does” or “explain the difference between HTTP GET and POST”. These questions are not bad per se. They do cover some of the most essential concepts one needs to understand to be an effective web/frontend engineer. The problem I have with this particular practice is the way the knowledge is tested—by having the candidate to verbally explain to the interviewer.

First, by doing so, the interviewer might fall into the trap of green lumber fallacy, a form of bias where one thinks that being able to define a thing correlates with the ability to use it effectively in practice. Anyone can recite the definition of closure from a blog post or Wikipedia. But, it is not the same as being able to apply the knowledge when writing code.

The worst kind of interviews I have experienced involve rapid-fire trivia quizzes of programming concepts, one after another. It feels like the interviewer has a list of facts that the candidate must know in order to pass the test, with no discussion or exploration of the topics. This approach is one-sided and one-dimensional.

What I would do instead is to design a question where the understanding of closure is needed in order to arrive at a workable solution, and work with the candidate to solve that concrete problem. This is much more akin to the day-to-day work of development. During the pair programming process, sometimes conversations about those programming concepts just happen naturally.

Ask overused questions#

Time-honored coding questions, such as reversing a linked list, should be retired. For frontend specifically, a good equivalent is writing a debounce utility function. While these questions do test core programming competency, they are so well-known and overused at this point, leading to false positives.

Don't be lazy; come up with interview questions that are original and better suited to the skills your team needs for the jobs they do.

Mix behavioral and coding questions in the same round of the interview#

This could be the most controversial take of the three discussed in this post. I don't like when many interviewers spend the first 10-20 minutes of a coding interview asking behavioral questions like "what is the most difficult project you've done?" or “what have you been working on lately?” It's equally bad to insert a quick coding exercise into the middle of a behavioral interview.

Ideally, in a coding interview, the conversation before the coding exercise should be kept to a minimum: the interviewer greets the candidate, introduces themselves and the team, and quickly moves on to the coding question. The purpose of coding interviews is to assess the candidate's problem-solving ability. Avoid any activities that can be a vector for bias. Some interviewers I know even go as far as avoiding reading candidates' resumes before the interview. It's all about reducing noise and eliminating preconceived bias.

This is not to say that behavioral questions aren’t as important—they are. That’s why a comprehensive interview process should include at least one behavior round, where the interviewer can delve deeper into the candidate's past experiences

Closing thoughts#

With the plethora of platforms such as LeetCode and Interviewing.io dedicated to helping candidates prepare for technical interviews, it's clear that in tech industry, there is a glaring imbalance in the resources invested in preparing candidates to excel in technical interviews and those that educate interviewers on how to fairly and consistently evaluate them.

I believe the state of technical interviewing in our industry still has much room for improvement. I encourage people to continuously reflect on the interviews they've run and re-examine the well-established practices.