The Rubik's Approach
Posted by pramatr on January 29th, 2009
Hiring new staff can be a long and drawn out process, at the end of which you hope you’ve found the right candidate. Vetting resumes, collating a list of potential candidates, telephone screening and then eventually bringing them in for an interview…….. so what’s the plan? This is the most important decision you’re going to make about your interview process; do you give them the list of technical questions, some example code or should you include the the rubik’s approach?
The List of Technical Questions
The candidate is presented with a list of technical questions that start with basic questions and slowly move towards more difficult ones. These could be about language specifics, API’s they claim to know or anything technical that is related to their potential position. Anyone with a basic knowledge of development principles stands a good chance of getting a reasonable score with the basic questions. Most people can memorise answers to the general technical questions, but does that really give you an insight into their ability?
The Example Code Test
The candidate is asked to write some general purpose code or possibly something resembling code they might be expected to work on. Anything general should be quite straight forward for the candidate, but anything that expects them to write code to specific API’s could produce undesirable results. If the candidate has claimed to have a good working knowledge of an API they have no excuse, but if they didn’t use the API yesterday, last month or ever, should that really sway your hiring decision? Is this candidate really better or worse than the one before?
A Different Way?
Joel Spolsky keeps his criteria for hiring staff quite simple; smart, and gets things done. If we approach hiring with such simple criteria; development is about solving problems and a good developer needs to excel at this regardless of their chosen language. They need a natural aptitude to understand a problem, break it down and arrive at a a solution. Presenting a candidate with technical questions or example code rarely tests those natural problem solving abilities in any great deal.
Rubik’s Research
A recent batch of company branded merchandise contained a single rubik’s cube. Over the course of a couple of months, the rubik’s cube was passed around the office, each member of the team having differing degrees of success. One team member was a rubik’s cube wizard, spinning and flicking the squares around to complete the puzzle in what seemed like seconds. This team member also happens to be exceptional at their job and has amazing problem solving skills. This team member is not a developer, but I have no doubt that if they decided to turn their hand to it, they would be an exceptionally productive one.
Some of the other team members just couldn’t break the problem down and struggled to find the patterns that advanced the puzzle. Even after training from the rubik’s cube wizard and written instructions on how to solve the puzzle, some team members still couldn’t progress from the jumbled mess. Some of these individuals could be classified as average (not exceptional, but not bad) developers and this puzzle really seemed to highlight the distinction.
The rubik’s cube is only one example of a problem solving challenge (some would argue one of the hardest), but even when supplied with the answers it still provides a good challenge. Fan’s of the classic game show Krypton Factor might already have an idea of the kind of challenges a candidate could undertake; from the impossible to the absurd. The idea here is simply that by augmenting a normal interview with a puzzle element, it may add some insight into the candidates puzzle solving approach.
Conclusion
The difference between average, good and excellent developers can often be traced back to their aptitude to solve basic problems. If team members are given the solution to problems but still can’t progress further, does this give us an insight into their general analytical approach? Problem solving skills can be taught to some degree, but does the rest just come naturally, is there only so much you can teach? Typical interviews often only touch on this ability and don’t look at it from a pure approach.
Puzzles like the rubik’s cube are a great way to test an individuals problem solving abilities, potentially putting them on a level playing field. These kind of puzzles force individuals to look for patterns, understand the process and apply it; after all isn’t that what development is all about? Next time you have a candidate in for an interview, should you include the the rubik’s approach?
Note: I have tried to find more information on this subject but as yet I’ve found very little real research. I’d be interested to hear about the links between problem solving and programming ability.