For some reason, the majority of technical interviews consist only of talking. Sometimes there’s a written quiz of some sort. Rarely, there’s a programming challenge; typically the candidate is free to complete the challenge on their own, in any amount of time whatsoever, in any manner whatsoever, with no opportunity for the interviewer to observe the candidate’s thought process or methods.
And yet, there’s general agreement that professional software development is a team sport involving collaboration skills as well as technical knowledge, and that software isn’t written once and discarded, but rather must be “habitable” for many years into the future. Weak screening methods don’t separate people who can handle that kind of work from those who can’t.
In some cases, there’s a meaningful programming challenge; sometimes involving pair programming with people who work at the company, to give everyone a sense of how the prospective new team mate will mesh with the team. But this seems to be exceedingly rare.
FizzBuzz is used quite a lot for this purpose. It’s a simple problem, and will quickly expose applicants who don’t have even rudimentary coding skills. Yet, it isn’t so complicated that people will get bogged down in the details.
Some of the popular code katas are also used for screening technical applicants, as they are generally of limited enough scope to be practical while presenting enough of a challenge to provide a useful assessment of the candidate’s basic programming skills.
But sometimes interviewers/screeners miss the point of using a coding challenge as part of the screening process. For example, Imran Ghory writes (in 2007), http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/
“Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.”
“Want to know something scary ? – the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.”
Want to see something really scary? Try this: scene from Twilight Zone: The Movie (1983).
Just kidding.
The really scary thing is that there are lot of people out there like Imran Ghory, who think that sketching out a quick-and-dirty solution on a piece of paper in two minutes is representative of the kind of work professional software developers do.
I like to use programming problems to screen applicants for programming jobs. But my goal is not to see how rapidly they can scribble crap on a piece of paper. I want to see how they approach the problem step by step. I want to see if they keep the code clean as they proceed. I want to see whether they use a test-driven approach, and have a chance to ask them their reasons for doing so or not doing so. I want to observe them making the decision to use recursion over iteration; composition over inheritance; or any number of other small decisions, and discuss their reasoning with them.
I want to see them do things they can’t do on a piece of paper. I want to learn things about them that I can’t learn in two minutes.
If the interviewer him/herself is ignorant enough to think a two-minute solution on a piece of paper is a Good Thing, and arrogant enough to disparage senior developers who take the time to demonstrate their skills properly, then I guess that’s a useful interview result…for the applicant.
It tells me the interviewer is more interested in showing off than in screening people for real work. I will leave them to do that without me. I encourage you to do the same.