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

        for( i=1 ; i< 10 ;i++)
                if(i%3 ==0) i++; break;
                if(i%2 ==0) i++;


Follow up: what happens if break is removed ?

  • 4
    This shows some aspects of programming language knowledge but how do puzzles like this show HTML/CSS/SQL/OO/ORM skills?
    – NoChance
    Jan 22, 2012 at 9:04
  • 4
    Why does everyone want to test programmers by having them do everything else except write code? This isn't marketing.
    – JeffO
    Jan 23, 2012 at 0:47
  • 4
    There are many other questions that deal with the issue of coding puzzles etc... How is this question unique, and how will it avoid the inevitable subjective opinions being thrown back and forth?
    – S.Robins
    Jan 23, 2012 at 2:37
  • 10
    Yes, if all your code is as nonsensical and intentionally misleading as this example...
    – MaR
    Jan 23, 2012 at 11:59
  • 4
    Testing to see if a person can read code and logically analyze a problem is one thing, that's good to check for in a programmer. Testing if they can spot an obfuscated trick (while under pressure at a job interview, mind you) is just mean-spirited, I think. Feb 10, 2012 at 23:09

10 Answers 10


What kind of developer are you looking for:

  • One who can take a set of requirements written as a riddle, and create code that solves the riddle?
  • One who can debug code that looks like a riddle? or
  • One who can talk to the users, and the ones who write the requirements; then create code that solves the problem, and meets the requirements?

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.

  • 10
    I'l add to this, what sort of industry are you in? Puzzle style interviews are certainly helpful for companies like Google who do tend to wrestle with problems like that in their daily work. Writing a web UI for Payroll? I'd rather have someone who's demonstrated a solid understanding of TDD and the web architecture stack. Jan 22, 2012 at 9:23
  • 3
    @Martijn Verburg If Google wrestles with difficult problems then why not give candidates actual problems instead of brain teasers? I think it is a question of how popular the company is - whether it can "afford" to look for the "best".
    – Den
    Feb 6, 2012 at 9:23
  • @MartijnVerburg - But if all you need is a web UI for Payroll then why hire a new employee for that in the first place? If that's the only development/coding that needs to be done you might as well just farm it out to a consultant. But if that's not the only engineering work that needs doing, it seems presumptuous to assume that the candidate will never encounter a challenging problem that requires them to think outside of the web arch. and TDD box. Anyone can be a code monkey; good developers are problem solvers.
    – aroth
    Jan 8, 2013 at 4:50

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.

  • 3
    I've just re-read Joel's article, and he uses "Add up all the values in an array"-style puzzles. I don't see why those puzzles are superior. IMHO this kind of exercise is better, because code is more often read than written.
    – nikie
    Jan 22, 2012 at 9:24
  • @nikie - sorry, but I have to disagree on the merits of reading code. If you can write code, reading will take care of itself.
    – JeffO
    Jan 23, 2012 at 0:49
  • 6
    @Jeff - I totally disagree with your if you can write then you can read theory. The overwhelming majority of developers cannot read code. They can write it, but can't figure others code out very well. Being able to put yourself in another developers mindset and figure out what they were doing is a skill like any other. Certainly if the code is written well then most developers can figure it out. This is like reading a first grade text. But most production code eventually ends up not nice. More like reading a college text. Most developers are not able to read this within reasonable timeframes.
    – Dunk
    Jan 23, 2012 at 16:57

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:

  • Puzzles for the sake of puzzles. Maybe they're meant to test how a candidate thinks under pressure. Maybe they're meant to look for agile learners or the like. I don't really care - I hate them. I'm terrible at puzzles, and honestly if I hit one in an interview that felt very much like I was just being tested on how much I suck at adventure games, I'd probably say something. I'd like to say these don't crop up, but they do.
  • Code reading puzzles. Like the one in the OP. I'm...not necessarily convinced of their utility. It often seems these are somewhat poorly written code to begin with, follow bad practice, or are really contrived.
  • "Spot the algorithm" puzzles. The ones you occasionally see in 'Solve this, work here' ads on public transportation, where really you'd just be looking for someone familiar enough with some concepts that get applied in your field. I could see these being useful if your particular application is filled with a particular type of problem.
  • FizzBuzz and related "do you know a concept" puzzles. These I think are decent for testing basic skills.

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:

  1. Iterate through all the integers between 1 and 1000. Take the square root of each and see if this is equal to the truncated-to-integer result of the same calculation. (No modulo operator in Applesoft BASIC!) If so, print the number.
  2. Iterate through all the integers between 1 and 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.

  • There is a third approach, which is to write a one line function: print 1, 4, 9, 16, 25, 36, 49, 64, 81, ... Feb 6, 2012 at 17:50
  • Heh, indeed. :-)
    – kindall
    Feb 6, 2012 at 18:03

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.