Interviewing candidates for an open job position is hard. Period.
No matter what process or methodology you use, in the end it comes down to trying to summarize a persons skills, personality, work ethic and team fit within a relatively small allotted time. Not an easy task.
As an interviewee I’ve participated in many different interview styles that companies had ranging from a brief single discussion with the hiring manager to the grueling eight hour interview with standardized testing, five one on one interviews and a case study.
What I’ve found is that, along with most things in life, a style somewhere in between both extremes works best. Keeping in mind the damage hiring the “wrong” person can cause – lower productivity, morale problems, inter-team social issues, etc – we can immediately see that any extra effort needed upfront to setup a process that works will yield greater results in finding the “right people” and pay us back in the long run.
The Interview Process
There are many ingredients you can choose from when thinking about what to include in your interview process. The list below contains some of the techniques I use in interviews I participate in as well as some that others might be familiar with.
- One on one interview
A individual discussion between the candidate and a key team member. To be most effective this should be someone at least technical enough to distinguish between someone who knows the technology or area being discussed and someone who is good at talking around an area.
My opinion is that the interview must be with at least one individual that would be considered a “peer” or have a close working relationship with whoever is hired into the position.
– Lower stress than a group interview
– Can get multiple reads on the same areas from a candidate
– Time can be a factor if there are several individuals on the team you want the candidate
to speak with
– Need to reconcile each interviewers perception of the candidate. More difficult when
there are discrepancies in perceptions of the candidate.
- Group interview
The group interview is one of those techniques that if done correctly works well and if not done correctly is a complete disaster. The idea is to have several key team members in the interview at once all taking turns interacting with and asking the candidate questions.
– Allows multiple team members to evaluate the same answers given by the candidate
– Can leverage the experience and specialties of many individuals
– Allows those not currently interacting with the candidate to focus more on the responses
from the candidate
– Less chance of difficult reconciliations since all interviewers hear the same response to
– Higher stress environment for the candidate
– Can feel like a “firing squad” or inquisition if not done right
- Standardized testing
Standardized testing usually takes the form of a non-technical assessment of a candidate usually focusing in on behavioral, reasoning and logic questions.
– Easy to compare results across candidates
– Useful if your team believes there is a direct correlation between the success in the job
position and the generalized knowledge being tested
– Some people aren’t good at taking tests, especially under pressure. May result in loss of
- Written or Verbal technical assessments
Written or verbal quizzes on the applicable technology areas your team uses. Can cover a range of topics and skills levels from basic knowledge to advanced concepts.
This should not devolve into a syntax assessment, as most programmers rely heavily on documentation, Intellisense and reference material for syntax, although the more familiar with the syntax a candidate is, the likelier they are to have been using the technology more recently and frequently.
– Easy to determine whether the candidate has used the technology and has a firm
understanding of the underpinnings
- Reviewing of code
The intent of having the candidate read code is to determine a few things:
– Do they understand the programming language being used.
– Can they understand someone else’s code. A good portion of your product is
likely written already. If the candidate can’t read and understand this existing code
that may be a problem. Most companies can ill-afford the employee who needs to
rewrite / refactor every area they work in so that they can properly understand it.
– Can they intelligently talk about a piece of code and what some of the characteristics
of it are – Usage patterns, good things, things to be improved, etc.
– Good read on the candidates ability to understand code. Something not obtained
through verbal/written technical assessments.
– Stressful for the candidate as they will feel pressured and “on-stage”
- Spot the bug / Troubleshooting Exercises
This technique usually involves having the candidate review a piece of code or application that has a bug in it. This exercise can be tailored to be very light or more complex.
A light version of this would be to have the candidate review a set of short code blocks with issues or bugs in them. These could be highlight core mistakes in the understanding of a concept to a more esoteric ones. These also should not include syntax problems that would be easily picked up by a compiler as most developers tend to rely on this.
For a more complex exercise, the candidate could review the companies actual product where bugs have been introduced into the code. Since the code would need to run to be worked on by the candidate these bugs would not be syntax related.
– You get the candidate doing exactly what you are hiring them for- working with code.
– Provides a good insight into a candidates ability to troubleshoot, identify and correct
code. What a concept!
– Candidates might feel stressed having to work with code in the interview. This can
be alleviated by leaving the room, or by interacting with the candidate as they work –.
answering questions and guiding them (although not directly to the answer!).
– Depending on the bug introduced and the subtleties / complexities of the scenario the
candidate might not be able to identify this. Make sure the bug is relatively apparent, or
better yet have multiple bugs ranging from easy to more complex.
- Design Problems
The technique referred to here are programming design problems, not esoteric ones. Usually involves describing a hypothetical system or problem that needs to be designed by the candidate giving them just enough details to start – barely.
The exercise usually involves the candidate coding the problem on a provided computer.
The premise behind this technique is that you want to be able to gauge how well a candidate can take a set of instructions and break them down into a well designed program. The main takeaway from this technique is the thought process and decisions that the candidate makes along the way and not the final outcome.
In fact we usually don’t have the candidate finish whatever problem was chosen. Observe things like:
– Did the candidate ask clarifying questions on the requirements/premise of the problem
– How did the candidate approach the problem – dive right in coding, draw it out, ask
– Did the candidate consider the appropriate tradeoffs in design – speed, performance,
Remember that the focus is not on the end result but on how the candidate approaches the problem and works through it.
– Provides insight into how a candidate thinks about problems and design considerations
– Can be used as a gauge of experience, familiarity with tools, language/project choices, etc
– Pick an area that is unfamiliar to the candidate. Make sure the problem is a fairly well know
concept so it doesn’t require and explanation aside from the intended requirements.
– More stressful than direct interview discussions since the candidate will feel like they are
“on-stage”. Be sure to explain the intent of the exercise is to see their approach to the
- “Try before you buy”
Pairing the candidate up with a team member for a time period on a current project and let them code together. This appears to be more applicable when the team is following an Agile methodology.
– Useful to see the candidate in action. Coding style, thought processes, etc.
– Able to get a rough gauge on team fit, personality.
– Time. This requires a long time commitment by the candidate
– May not work well with a candidate that is not familiar with the Agile methodology. Most
non Agile shops don’t have programmers pairing together.
– May be difficult for candidate to participate and demonstrate anything useful due to lack
of knowledge of the feature, code, etc.
In the end what you choose to be a part of your process must be based on what works for your team and business culture and the amount of time you can invest in each interview.
Some of the techniques I find the most useful in interviews I participate in are the “hands-on” techniques. If I am hiring for a developer, then I want someone who can read and write code. If I’m in the interview, you will need to convince me you can code.
Let me hear from you if there are techniques you find work better than others for your team, or if you have any ones I haven’t listed here.