Technical Interviewing

Technical interviewing isn’t easy. It’s not easy for the candidate, but it’s also not particularly easy for the interviewer. As a hiring manager, it’s easy to fall into a number of pitfalls which may come back to haunt you in the future. Here are a few options that I’ve seen over my years in this field. 

 

This is a classic. What’s the easiest way to do a technical interview? Come up with the same list of questions to ask your candidates and run through them. You know what the answers need to be. Scaling it is easy— just give everybody who’ll be doing the technical interviews the same list, have them vary the order, and go for it. Problems: A smart interviewee will jot down the questions you asked. Ever seen a 15-deep referral chain of unqualified interviews filling positions at your company because they aced the technical and were perfectly qualified in all other ways? 

 

From my perspective, this is just a variant on the list of questions, except with a significantly bigger time investment from the candidate. (Or less, in this brave new world of ChatGPT regurgitated code and easily searchable github profiles). Also as a technical contributor myself, I have a love/hate relationship with these. It all depends on the follow up. Are you making a decision based on the code? Then it’s pretty much the list of questions. Are you talking with the candidate to have them walk through the code? Great! But then you need very specific guidelines. Anybody ever walked into an interview where you had a take-home, and get that sinking feeling when the interviewer says “I have never seen golang before” when your entire implementation was in golang? (The interview problem said “your choice of language”!) 

 

This one drives metrics-oriented people nuts. How do you quantify a hour (or two, or three) long conversation to a quantifiable yes/no answer? What if it’s multiples? This is where technical hiring becomes more of an art than a science. The nasty reality that a lot of technical managers don’t necessarily want to admit is that in a lot of cases, training a well-fitting employee is a much better path than hiring a poorly-jiving expert in the field. And even if you’re hiring for a technical role, most work is really communications. (Yes, I love the mostly solitude rack & stack roles of the datacenter, or the long NOC night shift too, but those are becoming fewer and further between). Conversations are also a two way street - they can expose as much about the interviewer as they do about the candidate; is the interviewer able to be humble enough to not become upset about this?

 

There is no perfect solution. In reality, what I’ve defaulted to is some sort of combination of all three. Putting candidates into a scenario, and seeing how they react is a fantastic way to go about it, but it doesn’t always work either. Sometimes you just need to have a conversation with a person to really grok what their experience and history is. Sometimes the candidate on the other side of that table is better than you at your own job. Sometimes you will make mistakes and hire the wrong person, it’s always a risk, but like that old movie, the only way to prevent that scenario is to not to play. Unlike that movie, not playing that game is not an option. Treat it as an opportunity. Often in the tech world, I hear folks say “Hey, ask questions, you’re interviewing the company as much as they are interviewing you.” But for those of us that are on the hiring side of the equation, it would do well for us to remember that when the candidate steps into that room, or joins that call, they really are interviewing us as much as we are interviewing them.