Common Mistakes When Hiring Software Engineers
What are some traits shared by the best programmers you know? I'd wager things like introversion, thoughtfulness and detail orientation show up on your list. While none of these are requirements for a great programmer, they appear disproportionately represented among the best coders i've worked with.
This is important to note. It means we should make sure that the interview processes we put candidates through are not biased against any of those traits. If our process were to be biased against those traits we would risk rejecting qualified candidates for reasons that have little to do with coding ability.
The problem is they are biased. Engineering interview processes are torturous for the fast-speaking, extroverted among us. They are a great deal worse for the thoughtful introverts.
So how do we fix this? Perhaps first we should examine common practices in coding interviews that are detrimental.
Whiteboarding
Does your company whiteboard its candidates? If so, stop.
Whiteboarding is a practice borne from what i can only assume is equal parts social ignorance and intellectual dick-waving. The idea that this practice is representative of coding, or coding ability, is nonsense. Furthermore, the practice is clearly biased against each of our above traits. Just think about the introduction of this practice:
"Hey Tim. I'd like to you stand up at the front of this room on display for all of us and work through this admittedly tricky problem. Don't fret about the details though, psuedocode is fine. And please, try not to rush in spite of your increasing awareness that each moment you stand there perspiring and struggling is time that the rest of us reviewing your solution would rather be doing our actual jobs. But i digress. Good luck!"
Staged Collaboration
The value we need to replace in the absence of whiteboarding is the ability to "see how candidates think." This can be achieved more successfully with a pad of paper and a pen. Having a candidate sit at the table in a comfortable writing position goes a long way by itself.
Another helpful approach to gauging candidates thought process is to stage your interview problems so there are a series of asks and check-ins. Breaking large problems into Ask, Check-in, Review, Repeat allows you to keep each info block confined, focusing your candidate and keeping them from stressing about retaining lots of information.
Better yet, design your interview question to be missing important details. This will give candidates the opportunity to discover the need for these details when they get to them and ask for them at that time. If the candidate never asks questions, great! You just identified a serious red flag you would have been hard pressed to find otherwise.
Conversational Relationships
The idea that an interview starts when a candidate walks into the room is false. For candidates, each interaction they have with your company shapes their perception of the culture, and people, there. This means that if you present a serious, corporate vibe from the start you should expect candidates to bias their communication similarly.
This causes problems if you drop them into collaborative problem solving during on-site interviews. They will keep their thoughts and cards closer to their vest.
Instead, i've found it best maintain a more casual, conversational relationship with candidates throughout the process. This enables a lightness all too often absent from in-person interviews. It allows for smoother collaboration that is more representative of the person who would walk into work everyday, instead of the Corporate Interview Representative(tm) you will often get otherwise.
Open-Ended Discovery
This topic really deserves a post unto itself, but i must touch on it here. Too many interview questions have a predetermined solution. This is sub-optimal. Assuming 5 candidates find the right answer, what differentiates them? Speed? Outspokenness? Approach? None of these are powerful indicators of coding ability.
Instead, asking open-ended questions can reveal the depth of understanding on a topic. Consider the following SQL questions:
- This query (hand them sql) is running slowly. How do we speed it up?
- Our production server is slow, how do we fix it?
In each case, we have a desired outcome. We want to know well the dev is at optimizing SQL. But in the second question we get so much more depth of understanding. In the second case, a skilled candidate will ask questions about all kinds of things from networking to cpu and ram, load, etc. We can shut each of those avenues down by answering each of their questions in ways that direct them right to the SQL. Once they get there, hand them the query you would from question 1.
This may feel like a roundabout way to get to what you want. It is. But so it coding and production performance.
Understanding
Discovering the depth and breadth of a candidate's understanding is nearly as important as gauging their ability to write code. You can extrapolate a lot from knowing how long someone has been coding and how deep their understanding of topics are. Interest, passion, intuition are all important traits in engineers that this approach can shed light on.
But this is a tricky thing to actually know in the short time you spend with a single candidate. If your interview is designed in a way that leaves candidates nervous and apprehensive you are doing both of you a disservice.
The goal of an engineering interview is not to find the candidate who is most confident or thinks on their toes the best. Coding interviews should identify the people who are most likely to be successful on your engineering team. So if your process isn't representative of that team and your daily operations, you are measuring the wrong things.
tl;dr: Design an interview process that is representative of your team and caters to the traits you find most successful in the position you are hiring for.
