Posted on December 3, 2015
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.

Opening Up a Techie

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.

Digging For Passion

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.

Draw Me a Picture

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.

The Pretenders

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.

You're Not Just Buying

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.  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.  That simple act of honesty and transparency will reflect well on you and your company.

Conclusion

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.
Tags:
experience interview knowledge problem solve

Doug Klugh

Doug is an experienced software development leader, engineer, and craftsman having delivered consumer and enterprise firmware/software solutions servicing more than one billion users through 20+ years of leadership.

Similar Articles


subject Article

Conducting Effective One-on-Ones

As a manager, you are faced with a variety of responsibilities and expectations, from above your position and below, that need to be fulfilled every day.  Through all the challenges and roadblocks, you need to drive your team(s) to deliver results while retaining and growing your team members.  But if you don’t have good relationships with your people, you will struggle to achieve these goals.

Read More
subject Article

Agile Is More Than Process

There is more to Agile than estimating stories, collaborating with customers, and showing working software.  Agile is also about technical excellence.  And this is where many Agile teams drop the ball.  All too often, teams focus too much on process and not enough on technical practices.  If the effort, complexity, and risk is too great for your team to extend and maintain their software, they will struggle to deliver functionality to their customers at the end of each iteration.  They will struggle to deliver working software as promised.

Read More
assistant Development Tip

Developer or Engineer

Are you a Software Developer or a Software Engineer?  There is a difference.  A Developer will write code that fulfills the customers' needs today.  An Engineer will build a solution that first fulfills the customers' needs for tomorrow, then only second, fulfills their needs for today.  Engineering a solution requires understanding which qualities need to be optimized and applying appropriate engineering principles to best achieve that optimization.  Some qualities are diametrically opposed and...

Learn More