Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am interviewing candidates for Java programmer positions.
My colleague insists in filling more than half of the interview with java coding puzzles.His view is that, if candidates are able to navigate through the loops, then they must be good.
One such example of coding puzzle is
i=0;
for( i=1 ; i< 10 ;i++)
{
if(i%3 ==0) i++; break;
if(i%2 ==0) i++;
}
print(i);
Follow up: what happens if break is removed ?
What kind of developer are you looking for:
I have never been asked to solve a riddle, or to write code as part of an interview. Most of the time the job has been as a solo programmer; other times it has been to take on a technology that the company is unfamiliar with; either way there is no easy way to construct and evaluate a riddle.
It depends what you use the puzzle for.
If you use it as a starting point, to see how a candidate approaches a problem and to fire up a discussion about programming techniques, style, and philosophy, then good.
If you use it as a black/white test, where the fastest candidate to solve the puzzle gets the job, then you're doing it wrong.
You want to evalute a candidate on a wide range of aspects: communication, out-of-the-box thinking, code comprehension, problem solving skills, general attitude towards coding, social skills, strengths and weaknesses, and whether they're a good fit for the team. Reducing all these to a single boolean "solved the puzzle" is never good enough.
If you're looking to hire someone good at puzzles then yes, it is a good approach. If you are looking to hire a good programmer you might want to take the approach laid out by Joel.
I think the key is to realize what the puzzle you come up with asks, and what it doesn't.
There's a few, of varying levels of (imo) utility:
I think there are two main pitfalls to this approach though. The first is being hard/opaque/clever for its own sake, like some sort of sadistic Dungeon Master. Why are you testing people for their ability to decrypt terribly written code designed not to be read or understood (I'll make an exception for places that already have a terribly written code base)?
The second is spending too much time on puzzles, and not really addressing what these value. Doing well on these types of questions indicate you're good at solving puzzles. Is that the primary talent you want in your employees?
Of course you can't ask only puzzles, and "gotchas" that revolve around language trivia are not very useful. But some kind of programming exercise is a virtual necessity if you use a staffing agency or recruiters, or if you keep hiring people who are good at faking their level of competence.
Asking the right kinds of questions can help gauge how familiar programmers are with common algorithms and how to apply them to problems. It can also tell you whether they look for multiple approaches and choose the best one, or just pick one that they know will work. In the latter case they may be aware that there is a better way but would need to look it up to get it right, which is fair enough -- working, if less than maximally efficient, code is better than code that doesn't work, and just knowing there's a better way is more than half the battle.
An example of a decent place to start is a problem I had in a programming competition back in 1985-ish, when I was a young Applesoft BASIC hacker. The problem was to print all perfect squares between 1 and 1000. Of course, there are two approaches to solving this:
SQR(1000). Print the square of each.Obviously the second is far more efficient than the first, and as a bonus it will print all the right answers, while the first, due to rounding errors in the Apple's SQR() implementation, actually missed one or two. However, most of the solutions turned in used approach #1. (These were high school students, after all, and the problem was posed in such a way that the reader would gravitate toward the first option.)
A discussion around a modern-day problem of this sort could reveal whether a candidate is a aware that there are two approaches, can tell which is better, and understands the limitations of binary floating-point math. In fact, I would say that someone who couldn't tell you why the second approach is better would be a poor candidate -- basically on the level of a high school student from 1985. This problem is only slightly more complicated than "fizzbuzz" -- and much less complicated than anything they're likely to actually be working on!
My point is to know what you expect to learn from such a question, and to not set them as pass/fail questions but to use them as jumping-off points for probing the limits of a candidate's knowledge. You can ask a series of increasingly difficult questions and see where they begin to have trouble.
You might ask, how do I tell from a series of programming exercises whether someone is smart enough to work on my team? And the answer is: you don't, you rank them in order of smartness and hire the smartest you can afford, assuming he or she is smart enough.
print 1, 4, 9, 16, 25, 36, 49, 64, 81, ...
Feb 6, 2012 at 17:50
I swear one of these days when someone asks me this kind of question I'm going to answer something like "I have a better suggestion. You fire any fool who writes code like this." Code like this should never make it past code review.
OTOH, I like puzzles. I find them fun. It has NOTHING to do with whether I can write decent, maintainable, robust code.
If I were to give a definitive answer, I would say no, riddles are bad for interviews. What if the person you are interviewing is great at puzzles, but lousy or maybe let us say inexperienced at Java coding. Maybe the riddle solver will be able to come up to speed quicker than the average programmer, but are you willing to wait? If you are hiring for a Java developer, hire someone who dreams Java in their sleep. Perhaps if the environment were one where projects and technologies change quickly and the applicant might be programming in a number of different languages on a number of different platforms using a number of different frameworks in the next 2-3 years then I would be more inclined to go with the riddle solver.
I wouldn't call this a classic puzzle, as discussed e.g. in this question. I would call it a code reading exercise. Almost everyone agrees that puzzles only measure if a candidate has seen this kind of puzzle before. But code reading exercises can make sense, IMHO, developers spend a large amount of their time reading code, after all.
But personally, I would use code that's a bit more realistic. For example, I have a function somewhere in my codebase that breadth-first traverses a tree. If you strip the name, a reasonably experienced programmer should still be able to figure out what said function does. And answer questions like "what will happen if that data structure is a graph with cycles instead of a tree?" or "what would you have to change to get depth-first search?".
I've never thought coding puzzles are particularly effective at discovering whether somebody has a good knowledge of code or of problem solving. Usually I find the kind of problem soving required for them is rather different to the kind of problem solving when actually writing software. They generally have no requirement to think creatively. COntrast this with the Google type of interview question "How would you come up with a price for washing all the windows in Seatle?" This requires creativity and problem solving ability, but can be applied to any programming language you are going to use in the future.
These puzzles are simply a proxy to measure your IQ, or at least your logical reasoning skills. The obvious rationale is that, in the long run, a clever person will learn whatever technology stack they are using, whereas nobody can increase their intelligence. Does intelligence has a strong positive correlation with being a good programmer. I suspect so, however there are many more variables and experience cannot be brushed off so readily.
I think using puzzles is not a bad method, possibly a combination of puzzles and actual coding would be best.
In my opinion, the worst method is face to face interviews since you are seeing that person and you cannot help jumping to conclussions in just 30 minutes based on spurious assumptions (whether the candidate is fat, stutters or speaks slowly or, conversely, is very articulate). Even if you are aware of this, you will still unconsciously discriminate based on arbitrary variables.
