Thoughts on Interviewing: I

Our 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.

Great Developers  

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:

• Write well-crafted code using Quality Code practices.
• Communicate well with technically minded and less-technically minded people equally.
• Teach the rest of the team and learn from the rest of the team.
• Ask questions, and add to the understanding of the team when it comes to design, implementation and all other steps in the SDLC
• See areas for ingenuity and creativity in the code and processes that the team uses.

Did I miss anything? Probably, but this is a good starting point to talk about how we can better interview and hire developers.

What’s wrong with what we’re doing now?  

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:

Gatekeepers  

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.

“Quick Chat” with the hiring manager  

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.

Initial Contact  

(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”

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  

“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

• First, the candidate is usually put into a room, where they will spend the day.
• Second (and more egregious), the interviews are often conducted by groups of people who may or may not be part of the team the candidate will be on.
• Third, the candidate usually has another round of white-boarding (and often white-boarding with each group of interviewers). See white-boarding above…

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.

No Feedback  

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.

Wrapping up  

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