Skip to content

December 3, 2015

Conducting the Technical Interview

by Doug Klugh

With a shortage of technical talent, many of us are competing to find and hire the few technical rock stars out there.  And among those rock stars is a lot of mediocre talent trying to capitalize in a very good job market.  It’s hard to blame them for wanting a slice of the pie, but as leaders, we need to wade through the mediocrities to find those who can effectively support our development goals.

Having interviewed hundreds of candidates for a variety of development roles, I have developed some effective best practices for weeding out the cream from the crop.  While traditional interview questions provide some value, determining the technical competency of a candidate is not always as straight forward as you would think.  People who are highly technical tend to be pretty soft on soft skills.  That’s just the nature of the work.  A lot of time spent with a computer and less time with people.  They do well at building technical skills while losing interpersonal skills.  So as brilliant as they might be, they’re not always the best at communicating (although the rock stars find a way to be great at both).  While candidates may struggle to give you a great answer to a textbook interview question, in many cases, their true competency is much higher than their answer would indicate.

The best way to identify the top candidates is to simply have a conversation with them.  Don’t follow a script and don’t inquire from a list of prefabricated questions (although I will qualify this later).  Simply have a discussion around their experiences, challenges, and goals.  Talk about the skill set listed on their resume and deep dive as far as you can on the skills you need, for as deep as their knowledge and experience will take them.  This is where it helps to have your most senior team member in the interview.  And if the candidate can deep-dive farther than your most senior member, then there is your (potential) rock star.  I say “potential” because if they begin talking out loud to the voices in their head, you may need to proceed with some “other” (non-technical) topics.  I have seen a lot of great candidates fall flat when answering typical interview questions, but when you talk about how they have implemented specific technologies, suddenly the begin to shine.  Do you really care about their pre-constructed answer to “What is your greatest weakness?”  I don’t care to hear the best answer they came up with (or read in a book) for typical questions.  I want to hear them talk about their experiences and hear their passion (or lack there of) for the work they do.  I want to hear their opinions and understand their justifications for past decisions.  I want to know who they are and what makes them tick.  You won’t learn any of this by asking static questions.  You must have a dynamic discussion with a fairly loose roadmap.

And don’t forget the whiteboard.  You need to look into the candidate’s mind to see how they problem solve and how they attack the unknown.  For any role that requires any level of coding (implementation, test automation, build engineering, etc.), I always set up scenarios and ask them to code solutions on the whiteboard.  In terms of difficulty, I’ll start in the middle, and work my way up or down, depending on how well they do.  Eventually, I give them a problem difficult enough that they cannot solve and ask them to go as far as they can.  Watching how they deal with things they can’t figure out provides a wealth of information on how they think and how they problem solve.  And it’s good to see how hard they try to solve a problem before giving up.  Or how many questions they ask in an attempt to further understand the problem or to discover a solution.

With all of that being said, I understand the need to conduct interviews in a consistent manner.  You want to be fair to all candidates and judge them within the same playing field.  So some standard questions are required.  But for technical questions, you need to get past the textbook answers.  Smart people can read books or go through training, then successfully answer interview or test questions.  That does not mean they’re able to apply that knowledge or that they actually have the experience their resume depicts.  Know your topic (or get people in the room who do) and have a casual “user group” discussion around your technical needs.  If the candidate is a rock star, or even just very good in that role, it will become apparent through your discussions.  Unfortunately, in most cases, the candidate will struggle just to talk about basic concepts or past experiences.  Usually about half of the resume will be fabricated from a wish list of skills.  But if a skill is listed on the resume, it is fair game in an interview.  If the candidate has a skill listed, they better be prepared to talk in depth about it, even if it is not required for the position.  I always look for a candidate to say up front that their level in a particular skill is short of competent.  I must see open and honest communication before I will even consider a candidate.  No one knows everything, so look for what they don’t know and how easily they admit it.

Keep in mind that selecting the best candidate should not be the only goal of the interview.  While the candidate is trying their best to sell themselves to you, you must sell yourself, your leaders, and your company to them.  And if you wait until you know you like them, it will be too late.  You must begin selling the moment the candidate  walks in the door.  If they are a rock star, they will certainly have their pick of who they want to work for.  And if they’re not the best candidate, don’t let them leave feeling defeated.  If you know during the interview that they’re not a fit, cut the interview short and give them feedback (including positive feedback).  Don’t simply hand them off to HR to deliver the rejection.  The candidate will appreciate the immediate feedback and not having to sit by the phone, hoping for an offer.

Conducting successful interviews takes lots of practice; technical interviews being especially challenging.  Balancing your technical needs with an acceptable level of soft skills and cultural fit will be the toughest part.  At the end of it all, if you don’t have a clear winner, then build a consensus and trust your gut.

Leave a Reply

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

required
required