Thoughts on Interviewing: I
Posted on April 12, 2023 • 5 min read • 930 wordsOur interview process is broken. Here's the first in a two-part series on my observations and ideas to fix the process.
As a developer for over 30 years, I’ve come to realize several problems with the way we interview in the Software Development industry. Whether it’s because we don’t know how to correctly interview for a development position, or we’re not allowed to interview in the way that’s needed, it needs to change.
As a Senior-level Code Crafter, I’m finding it frustrating to interview with (and do interviews for) companies that have processes counter-intuitive to their desired outcome of hiring a great developer.
Let’s start by defining what constitutes a great developer. A “great developer” is a developer that can do several things (often at once).
They can:
Did I miss anything? Probably, but this is a good starting point to talk about how we can better interview and hire developers.
Here’s an example of the what I see with a majority of companies trying to hire a senior level developer.
The cycle goes like this:
Resume’s get submitted to HR recruiting manager.
This person may know a little about what’s actually needed for the position, or may just be checking off boxes. I’m not going to stick on this step, as often it’s easy to pass through, either by listing correct words on the resume, or getting a referral to a position from an insider.
Again, a simple check to make sure that the applicant is personable and has an idea of how to do the work of the team.
(optional) The applicant gets a timed code challenge using an online IDE like HackerRank
An hour-long “Phone Interview” with a Senior or Lead Developer/Architect/Engineer.
This is the “tell me about something you did that was great” question time.
Not a great step in the process. Most often the interviewer is looking for keywords that fit the current task for the position they are trying to fill. This is also the time for the applicant to write code in an online IDE, basically “online white-boarding”
Let’s stop here a moment and talk about “online white-boarding”, whether in the guise of a timed challenge or as we often hear:
“We want to know how you think.”
White-boarding (online or in person) is not a way to learn anything about a programmer’s ability or knowledge.
Actually, I take that back. White-boarding will tell you whether the programmer has seen/solved the problem you’re asking before.
White-boarding is really just a way to say to a candidate:
“We want to see if you can come up with the answer that we came up with.”
If it is really about understanding how a candidate solves a problem, have the candidate develop in the IDE that you use every day for your regular work.
No one that I know develops on a whiteboard.
“The Loop” has become an industry standard for the interview process, and it makes sense. This is where a candidate meets with three or four different interviewers over a couple of hours. This process lets the company schedule a time that works for all the interviewers, and the candidate can dedicate a time to focusing on the company.
The problem with this practice comes more in the individual interview times
This is usually the last step before a decision is made to hire or not. Which is good as it means the candidate doesn’t have to wait long for an answer, but in most cases, the company still hasn’t seen the candidate write code with the team.
Finally, most companies nowadays will not give feedback on how a candidate did in an interview. This is a mainly fear-based decision from HR, so that the company doesn’t expose itself to a possible lawsuit or legal action.
How do we except our community to grow without feedback?
Many candidates I’ve interviewed but rejected were so close, that with a little feedback and time, they could have come
back and been a good addition to our (or another) company.
Why is this the way that most interviews are done? My guess is that it’s a mixture of “Because we’ve always done it this way” and “Because we don’t know any other way”, or “Because it works for us”.
But is this what we really want as a software development team?
Does this get us a great team member, or does it get us the person that fits a position?
Interviews shouldn’t be seen as a way to measure the knowledge of a candidate, but more as a way to gauge the fit of a candidate into our organization.
Let’s talk about a better way to do this in Part II