On Conducting Technical Interviews…

As a software consultant, I’ve both gone through and conducted a fair share of technical interviews. By conducting interviews, being interviewed and watching others interview, I’ve learnt a few things myself. Below are some tips on what works and what doesn’t when interviewing software developers…

1. Ask the Candidate to Write Some Code!

IMHO, this should be one of the first filters. The coding question should be simple enough that it would take a decent coder less than 5 to 10 minutes to code. The purpose here is to filter out the “talkers” from the “doers”. For instance, if the candidate is having trouble coding a method that reverses a string, then it doesn’t really matter how many years for experience they have, what company they last worked at, or how big the project was! If they are having trouble remembering that a string is char[], then they are not someone you want on your team.

This little test may sound too easy or “something that anyone should be able to pull off”, but you’ll be surprised at how many candidates will be unable to write a simple method when asked to do so.

For interviews that are conducted remotely, you can have the candidate share their screen (I typically use Skype or Join.me), ask them to open up Notepad and code the solution.

2. Separate the Behavioral Interviews from the Technical Interviews

Be fair to the candidate – let them know ahead of time what sort of interview will be conducted and by whom. It’s very confusing for a candidate when behavioral questions are mixed-in with technical ones. This is because behavioral interviews require answers that contain a different vocabulary and are geared towards a different audience. The candidate that is answering a behavioral question is usually careful to answer the question at a high-level without getting into the nitty-gritty technical details. The answer is more focused on their contribution, how well they worked with others, how issues were handled, etc. Whereas a technical answer would cover things like: what specific technology was used, how was the functionality broken out, what sort of development model was used, what approaches did they take to test their own code, etc.

Letting the candidate know what sort of interview is being conducted and by whom will enable them to put forth clear and appropriate responses.

Which brings to my third point…

3. Please Have the Candidate Go Through AT LEAST One Technical Interview!

It’s surprising how many managers, that haven’t looked at code in ages, feel they have sufficient knowledge to hire a software developer. Software development is changing – rapidly! The skill-set required 5 years ago (or even a year ago in some cases) is quite different from what’s required today. So you if haven’t kept up, you will have no way of knowing whether a candidate is right or wrong when they tell you that an ORM is an Object-Role Model that allows you to map roles (yes, I did have a candidate tell me that). By all means, have the managers do the behavioral interviews – which, by the way, is a crucial part of the selection process – but please leave the technical interviews to your technical folks. If for some reason, you’re not in a position where you can have your own developers do the technical interviews (and there are many valid reasons why this may be the case), then hire an outside consultant to conduct the technical interview.

The last thing you want is someone who is adept at talking through the concepts and seems to knows all the technical buzz-words, but is very poor when it comes to writing code. And, for some odd reason, there are many “senior-level developers and architects” that are just that!

4. Skip Irrelevant Questions – Such as Brain Teasers

Instead, ask questions that require some creativity and thought to answer. For instance, say you want to find out whether the candidate that is being interviewed for a web development position has the habit of looking at and thinking about the big picture. One question that may help gauge this is: What are some common performance or security related issues that surround web development and what are some strategies to circumvent them? It’s okay if they can’t fully the answer the question. What you are looking for is whether such thoughts and questions have crossed their minds and how much time they’ve spent thinking about such issues.

Another example is to give them a user story from your actual project (after maybe simplifying it a little) and ask them to sketch an object model for the user story. What you are looking for is: What sort of class names they come up with, what sort of methods these classes contain, whether the relationships among the classes are represented correctly, does their overall object-model look “clean” and easy to understand?

Another question that requires some brain-power and creativity is to give them a user story and ask them to come up with a list of test-cases for the user story.

5. Find Out If They Actually Like (Nay, Love) Software Development!

Ask them if they are currently learning or have recently learned a new technology outside of work. What was the last software development book they read? How long ago? What did they learn from it? Any mentors, role-models they follow? Have they read or follow the following persons: Uncle Bob, Martin Fowler, Scott Hanselman? (Big red flag if they haven’t heard these names before). Where do they see themselves a year from now, five years from now?

Lastly, please keep in mind that these are my opinions that I have reached through my own learning and experimentation. You may or may not agree with them and they may or may not work for you – and that’s as it should be. Try them out if you’d like, modify them as you deem appropriate, and definitely invent your own.

Conducting interviews, much like giving interviews, requires constant refinement. Filtering out and selecting the right candidate out of a pool of qualified candidates is never easy. Hopefully, the above tips will prove somewhat beneficial to you while searching for the right candidate.