Technical interviews are the arduous rite of passage into a job. Although there is a growing trend in which a candidate is hired on résumé and testing alone, with no human intervention involved, most companies still want the bodies in the room. That’s the good news. The bad news is that many technical interviews lack a clarity of intention: Why are you interviewing someone and what do you want to know?
Let’s be honest. If you’re the hiring manager, you want to know two things:
- Can the person in front of me be trusted to do what we want him or her to do?
- Is the person in front of me going to get along with others?
If you are an engineer, you most probably you want to know two things also:
- Does the person in front me know his or her stuff?
- Can I work with this person?
That’s what it boils down to. A good technical interview process is comfortable, informative, and revealing in terms of the questions I listed above. You want to know as much about a candidate as you can, as quickly as you can, so you can make a wise hiring decision.
Thus, to help things along a little, I offer the Four-Step Process for Effective Technical Interviews. These steps are:
- Do your homework.
- Have a conversation.
- Do something together.
- Have a group interview at the end.
Allow me to elaborate.
1. Do Your Homework
A good technical interview process is one in which you know a lot about the candidate before he or she walks through the door. At interview time, you have a good idea what a person knows and has done. The interview is the time when you find out who the person is. This means doing your homework.
What does the homework look like? It’s about getting as much relevant information as you can about the person before he or she walks to through the door. That information becomes part of the candidate’s profile packet. Get code samples from GitHub. Look up the candidate on LinkedIn. Distribute the candidate’s résumé to relevant parties at least 24 hours beforehand. Also, provide evidence of the candidate’s competency to you before he or she comes in for the formal interview.
My practice is to describe a technical problem in writing, a problem that is within the scope of competency that is required for the position in question. Have the candidate provide a written response to the problem.
For example, if you are looking at a candidate who will be doing a lot of architecture work, provide a problem description that includes the technical issue at hand, the business case surrounding the problem, as well as the financial considerations in play.
Read the response very closely. As they say on the terrain, you can see a lot by watching. Of course, you want to look at the technical feasibility of the response. Also, look at the clarity of the writing as well as the thought given to the business issues at hand. Again, you want to know as much about the candidate as possible beforehand.
As I mentioned earlier, distribute the résumé as early as possible. My style is review the résumé carefully beforehand, not in front of the candidate. Why? Because in my opinion, it’s a showing of respect. Having a résumé before me as I talk to someone is a sign of lack a preparation and creates a dynamic of dominance. Why should I have the candidate’s résumé and he or she not have mine? Now, if you want to have a dynamic of dominance in which I, the interviewer, had more information than you, the interviewee, that’s fine. But, that’s not my style. I do my homework and then I….
2. Have a Conversation
A conversation is an exchange of ideas. An interrogation is an extraction of information. During the formal interview process, I prefer to have a conversation with a candidate. It’s the easiest way to achieve my objective: to find out how the candidate thinks and if I can work with him or her. The “does the person know his or her stuff” is determined as part of the homework we did. No way I am going to learn the breadth of someone’s knowledge in a 30 minute exchange. But, I can learn about his or her character.
I have come to discover that it really doesn’t matter what the subject at hand is. We can talk about baseball; we can talk about concurrent programming; we can talk about music. The essence of the person will come through no matter what the subject is. But, you may ask, “I need to understand this person from a technical point of view. How can get an understanding?” Which leads to….
3. Do Something Together
Usually, during the conversation part of the interview process, I will ask the candidate to help me solve a problem I am having, a real problem, not something I’ve made up for some Technical Interview Exercise. Let’s face it, all of us in the tech game have at least one technical problem on our plate at any given time. My style is to invite the candidate to help me solve mine. Nothing beats real stuff in the real world.
I have found that working together to solve a problem is where the rubber meets the road. Does the candidate have the communication skills to get the information from me necessary to pursue a mutual collaboration? Can I respond is a way that is relevant and comfortable to the candidate? Does a mutual enthusiasm develop? Is the candidate accepting and encouraging when I reveal that I have lack of understanding in a given area? Am I accepting and encouraging? Are we on our way to solving the problem in a meaningful, useful way? Are we having fun?
To use a musical analogy: Two people can talk about music all day long, but the real test of artistic compatibility is each picking up the instrument and playing together.
More than once, I’ve been able to solve a technical problem I am having because of an experience I’ve had during a collaboration with a job candidate. There is little downside to having a collaborative experience with another human being, regardless of whether or not the candidate gets the job.
4. Have the Group Interview at the End
I’ll share a secret with you, I am not a big fan of group interviews. Unless you are interviewing a candidate who will be doing a lot of presentations to groups of people, I find that group interviews to be of questionable value. Fifty per cent of the time is spent actually interviewing the candidate. Another fifty per cent is spent with each attendee posturing for the others in the group.
Yes, there is a good argument to be made that you can’t determine how a candidate will contribute to a group’s dynamic until the person is actually in the group. If that is the case, have the candidate interview with the group at the end of the day, after he or she has had individual time with each member. At that point, the candidate will have a chance to get to know each member as an individual and as a group member. All parties will have a better read of the situation during and after the group interview.
Also, putting off the group interview has an added benefit: saving time. By the end of the day you will have a good idea if you want to move forward with the candidate. If not, you can bring the interview process to a graceful close and avoid tying up a lot of people’s time for little benefit.
Putting It All Together
The reality is that you never really know if you’ve made the right hiring decision until a time well after the interviews have taken place, the offer has been made, and the candidate is on payroll doing work. It’s a crap shoot. But, you can put the odds in your favor when you engage in a technical interview process that allows you to make a hiring decision that is based on real world, collaborative experience coupled with accurate information gathered beforehand.
The Four Steps described above are a step in this direction. Take what you like. Adapt the the steps to meet your needs. Hopefully, my contribution will save you time and provide a way for you to find just the right person to hire.
