Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
4  
This shows some aspects of programming language knowledge but how do puzzles like this show HTML/CSS/SQL/OO/ORM skills? –  Emmad Kareem Jan 22 '12 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 '12 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 '12 at 2:37
8  
Yes, if all your code is as nonsensical and intentionally misleading as this example... –  MaR Jan 23 '12 at 11:59
3  
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. –  CodexArcanum Feb 10 '12 at 23:09
show 9 more comments

12 Answers 12

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.

share|improve this answer
9  
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. –  Martijn Verburg Jan 22 '12 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 '12 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 '13 at 4:50
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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 '12 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 '12 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 '12 at 16:57
add comment

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?

share|improve this answer
add comment

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 was 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 sqrt(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 an Apple's floating-point implementation, actually missed one or two. However, most of the solutions turned in used approach #1. (These were high school students, after all.)

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.

share|improve this answer
    
There is a third approach, which is to write a one line function: print 1, 4, 9, 16, 25, 36, 49, 64, 81, ... –  kevin cline Feb 6 '12 at 17:50
    
Heh, indeed. :-) –  kindall Feb 6 '12 at 18:03
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?".

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

According to Laszlo Bock, senior vice president of people operations at Google "On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."

share|improve this answer
add comment

I think the main problem with this is the implied approach -- it's basically a trick question, designed to confuse.

But it could be a 1 of 2 good interview question(s) with a simple change of focus...

  1. Ask them to spot the bug. Give the desired output, the actual output and ask them to fix it.

  2. Give them the code, ask for a code review -- give them ten minutes to write it up.

While reading code is a valuable skill, code like that just begs to be re-written. Hopefully most of your code doesn't belong on the daily WTF, and so presenting code that should be there and asking someone to tell you what it does seems less than useful.

Note that the 1st approach to this code is somewhat similar to what co-worker is doing, but has a different emphasis. The second is really quite different, as you don't want just a fixed version of it, or even a refactored version -- you want comments about it's problems. How the code could be improved and what is wrong with the code as written, even if it performs to spec.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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