This article is a part of Steve’s Guide to Conducting Software Interviews.
For the past several weeks I’ve been engaged in a full-time job hunt and have been attending many interviews for Software development positions at various companies. Job interviewing in any industry is stressful, I’m sure, and software is no different. It adds to the stress when I am sometimes surprised at encountering interview approaches which are ineffective, missing the point of the interview process, and sometimes downright dysfunctional, in my opinion. So I thought I’d weigh in here with some of my own thoughts on how to conduct an interview which has the best possible chance of resulting in a quality outcome – that is, optimally matching a candidate to the advertised position, on the off-chance that my thoughts on the subject can benefit someone out there.
Am I an experienced HR manager? No. I’m simply a guy with opinions who has attended a fair number of interviews. I’ve also conducted many interviews throughout my career and probably hired ten or so people. Looking back on those experiences my track record seems pretty good. Many of the people I hired went on to become highly valued team members and have long productive careers at the company (BlackBerry).
So I don’t have specialized skills in this area, only a bit of experience. However I have found that most of the tech interviews I attend are conducted by people like me – developers without any specialized HR training and often no hiring experience. So it is for that audience that I write my thoughts here, as a member of this community with a decent track record. In short: I’m not an expert, and if you disagree with my thoughts here feel free to comment and give me an alternate point of view.
I should also note that any thoughts I share here are with respect to the type of interview and position with which I am most intimately acquainted, that is to say, development jobs from junior to senior level, and low-level management jobs in Software Development. Human Resources Management is a huge field spanning all industries and sectors and situations, and I would never hope to make general statements that apply to all interviews. Rather, my advice is geared, like I said, to people like me interviewing within the Software business.
Also, I assume here that the goal of anyone’s hiring process is to build a highly effective development team that will grow and flourish over time. I understand that companies at times hire for very specific reasons and for very specific short-term goals, and for example may not care about aspects of an applicant’s candidacy other than a very narrow skill set. Still, I would tend to think that such an approach to hiring is ill-advised if the person you hire is going to remain on as a permanent team member following the completion of whatever project necessitated the hiring.
Looking back on my own experiences, there is only one hiring decision I made that in retrospect probably was not the best one. The individual I hired was a nice guy who got on well with the rest of the team, but was not a strong producer and in fact ended up requiring a lot of oversight by me. In that case, my reasons for hiring were based almost purely on Technology Fit (which as you will see shortly, now rates as my least compelling reason to hire someone), because at the time our project immediately required a resource with a specific skill set which this person possessed. So now I am a strong advocate of building great teams, and I think there is no hiring situation where the goal of fulfilling a short-term resource need should trump the goal of finding quality individuals who will add long-term value to the team and organization.
So with my disclaimers out of the way, allow me to present here a general template that I would follow for most interviews.
The following tools are the ones I rely on when choosing a candidate for a position, in order of importance (NOTE: not in the order that they’d necessarily appear in during the hiring process):
- Gut Feeling
- The Resume
- Examples of Previous Work
- Toy Coding Problems
- On-the-Spot Thought Exploration Problems
- Interview Questions
- Technology Fit
In subsequent posts I’ll go deeper into my reasons for each of the items on this list.