At my last company I was a team lead and, as such, was one of those responsible for interviewing new candidates. Although I didn’t enjoy the process much, I did become interested in the sorts of technical questions / exercises we could set to get a good judge of a candidate’s abilities.
Developer interviews typically cross a number of disciplines (often arranged in stages) that may include:
- a CV / résumé screening
- a telephone interview
- face-to-face questions and answers
- a technical exercise or written test to be done at home, or to be done in front of the interviewers
There is some debate as to which sort of technical exercise / written test is best: do you get the candidate to do it at home and send in their work, or do you make them do it in front of you, on the day? There are pros and cons to each approach; arguing for “at home”:
- The candidate is not nervous or under strict time constraints; they are much more likely to produce their best work
- If the work fails your acceptance criteria then you can dismiss the candidate’s application before the time-expensive process of interview (expensive for both the interviewer and candidate)
And arguing for “at the interview”:
- You can be sure that the candidate has not cheated, that they have truly written the answer themselves
- You get an opportunity to talk through the candidate’s solution with them; something they’ve done that might seem strange might have justifiable reasons behind it.
As you can see, there is a trade off. On the one hand, work done in the candidates own time is likely to be better, and the person grading the work also has as much time as they need to analyse the result. On the other hand, quite a few candidates will ‘cheat’ either directly, by copying existing answers to the problem or indirectly, by getting so much help from someone else that they haven’t written much code themselves.
The best solution as to which approach to use might not surprise you; it’s to use both. But wait, it’s as simple as just having both a “homework” exercise as well as an “exam” exercise. You should give the candidate an exercise to do at home and, when they complete it, grade it as you would before and decide whether to invite that individual in for an interview. During the interview you should produce the work they did in advance and ask them to talk you through it. Now comes the exam: ask them not to start a new exercise but continue where they left off.
Here’s a simple example: Candidates that survive the CV and telephone screening processes are asked to complete an exercise in their own time; in this case: FizzBuzz (in real life you shouldn’t really give them FizzBuzz; it’s too well known and, to be frank, too easy). Candidates’ submission can be checked for correctness, presence of unit tests, architecture & design, readability, over-engineering and so on. When the candidate comes in for interview you give them a laptop with their solution on it and ask them to walk you through their thought processes. This will tell you how they approach problems and how they design solutions, and how well they understood the problem space.
Next comes the clever bit. You give them the laptop and say “The problem has changed slightly, and you must modify your existing program. Now make it do this.” In the example of FizzBuzz you might say “as well as printing fizz for numbers divisible by three and buzz for numbers divisible by five you must now print baz for numbers divisible by seven (and combinations thereof, such as fizzbuzzbaz)”. This will show you several things: how comfortable they are throwing away part of their original design (good unit test coverage should give them the confidence they need), how much of their original submission they actually wrote, how well they designed their program for future-proofing and extensibility, and lastly (most importantly?) how they can cope with changing business requirements.
By the end of this process you will have a good idea of whether the candidate’s going to be a good fit for your company; you’ve witnessed their ability to solve problems and write algorithms, write unit tests, rewrite and refactor, and adapt to change. Should they pass all of these, you can be fairly sure you have a competent and worthy future team member.