<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1621132604871265&amp;ev=PageView&amp;noscript=1">

Seven years ago I joined a small software company. Business was growing, and we needed to figure out how to build out our staff. We had no HR people, and I was eager to demonstrate my value, so I volunteered to man an upcoming university career fair. What I thought was a one-day thing turned into hundreds of student resume evaluations, then dozens of interviews. Without really knowing what I was doing, my recruiting career was launched.

I’ve done a lot of things wrong, and I’ve learned many things the hard way. But with time and effort, I’ve become an effective programmer-interviewer, and I owe a lot of that success to thinking carefully about how I can better apply my programming expertise to the interviewing experience.

Are they for real?

When I first started interviewing, I began each interview by explaining my organization’s mission and value proposition. This would take a long time - sometimes 30 or even 45 minutes. By the time we got to the technical assessment, I had found that, more often than not, the candidate was not “for real”. They couldn’t program well - or, in many cases, at all. This resulted in nearly an hour wasted for both the candidate and me.

I decided to switch the format and put the technical screen first. Now, I begin interviews with brief personal introductions, followed by a confirmation that the candidate has everything he or she needs, and is feeling OK. But after about five minutes, I jump into the technical intreview questions.

During the interview, it may - perhaps immediately - become clear that a candidate is not for real. When this happens, I don’t hesitate to end the interview. Of course, interviewing needs to be done with a certain level of sensitivity - and I have tried very hard to cultivate empathy with candidates and let them down politely and kindly. But I wouldn’t be doing anyone any favors if I were to continue an interview once I knew he or she was a “no”.

For the questions, I don’t reinvent the wheel. There is no need; simple, well-known questions will do just fine. I lead with one that almost seems too easy - think Fizz Buzz. If you’ve not done something like this before, you will be shocked at how many candidates fail Fizz Buzz - even many with impressive resumes. I have about six, progressively harder questions.  If at any point it’s clear that the candidate is a no, I abort the interview. I would not call any of the questions hard; I would call them extraordinarily effective at filtering out the programmers who can’t cut it. There is simply no better way of assessing whether a programmer is for real than these simple screenings - so, in the interest of effectiveness, do them at the beginning.


Connecting to the known needs of the organization.

Programmers who do active development are perhaps best positioned to identify whether a candidate's ability connects with the tactical needs of the organization. Programmers are in the weeds. They are intimately familiar with the nitty-gritty details and technical challenges of their own - and often, others’ - projects.

Tactical fit, of course, isn’t the only consideration. But it does help in assessing how quickly the candidate can hit the ground running, and to what extent they can help solve the problems the organization is having today. I have also found that candidates advocated by programmers get a lot more buy-in from other programmers. If I am intimately familiar with one of my dev colleagues’ problems, and if I can bring on board a hire that I know can solve those problems, my colleague will be greatly motivated to make sure the new hire’s onboarding is smooth, and that he or she is happy.

We don’t know what we don’t know.

Knowing this creates opportunity - and a deep programming background greatly informs knowing where to look.

Invariably the best hires are those who possess valuable expertise that doesn’t yet exist in the organization. Sometimes this type of stuff isn’t immediately visible on the developer's resume - either because I don’t know how to interpret it, or because the candidate didn’t think to put it on. But I have found that this kind of expertise can create truly transformative, order-of-magnitude higher levels of value for our organization - and I wouldn’t have been able to excavate these opportunities if I had not been able to have a detailed, technology-oriented chat with candidates.

If you are a programmer-interviewer, I invite you to try these ideas and let us know the results. If you are not a programmer, I encourage you to enlist the help of an empathetic, knowledgeable programmer in implementing them - and as early in the process as you can. The effective implementation of these ideas can help you staff your organization with more amazing colleagues than you would have ever thought possible.

interviewing developers ebook


Schedule a 15 minute call

Call +1-877-782-2577 or email careers@stackoverflow.com for answers to any questions you may have