Something I don’t see enough of is developers who have a lot of recent interview experience (as an interviewee) being the interviewer. These devs are inevitably contractors so they are rarely chosen to be the interviewer in a company. Rather, the team lead who has been there for years is chosen. The thing is, as a person who has a lot of experience at being interviewed, I know the mistakes that interviewers make and they never get to learn this information. An candidate gets to correct their mistakes and become better at the interview process in preparation for the next one they do. An interviewer learns, 3 months down the line, that they have made some mistake but never learn what went wrong.
Here are some common mistakes that interviewers make:
1. Not testing the candidate’s argumentative skills. The interviewer should take a questionable stance on a topic and see how the candidate argues their point.
2. Never testing a candidate’s ability to read and understand code. Without this skill a candidate is more likely to reject your team’s existing code base and rewrite things from scratch. Instead of asking them to implement an algorithm (which, btw, they already may have practice doing - making the test pointless) get them to read a lot of regular code. Not a complex algorithm but something that spans multiple files and is quite large. It could be your codebase or something you found on GitHub. “Tell me what this does” “Tell me what you think is wrong with this code” “How would you change it?”. Being able to read code and write it are two separate skills and both need to be tested in the interview.
3. Making the candidate feel uncomfortable. For example, two interviewers against one candidate could make certain devs uncomfortable. Why is this important? A developer is going to get settled in the team at some point and feel comfortable. Wouldn’t you rather test them in that state rather than a state they would rarely be in? Unfamiliar text editors, interviewers watching you code; these are further examples. Sure, some devs are unfazed but others are, and they may be good devs that an interviewer is chucking away.
3. The interview should always involve a tech test and I strongly believe that the candidate should be left alone to do the test. However, this depends on how pair-programmer heavy the team is. Regardless, the most important part comes later when going through the results. So many interviewers miss the opportunity to question the interviewee on what they have written. It can be quite distracting if the interviewer is constantly picking through the code as it is being written.
4. Not going through the candidates cv during the interview. This should happen first and is part of the prep that an interviewer should make. As boring and full of exaggerations as other people’s CVs sometimes are, it is a good way to increase the confidence of the candidate so that the interviewer can get the most out of them for the rest of the interview.