The Zebra Puzzle: Evaluating Developer Potential Without Coding

In a previous career, I was a software lead who wanted to build a highly performant group of devs. Doing so usually requires either a) hire several all-star developers, or b) develop a team from scratch for high cohesion, and then grow them into all-star developers. Due to budget constraints the latter strategy was chosen. Since the team was going to be primarily junior- and mid-level developers, I wanted to evaluate their skill in a code-agnostic way.

It may seem strange that I wouldn’t want to evaluate their skills using code, but I had two major reasons. First, the team came from a variety of coding backgrounds, including some fresh grads, meaning they wouldn’t all know the same programming languages. Secondly, much like the brush that paints the canvas, or the hammer that hits the steel, code is merely a tool to express the savvy of the wielder. All that to say, I wanted to see their practical ability in problem solving, and my favorite way to do so was to observe them solve The Zebra Puzzle.

The Zebra Puzzle

To those who are unfamiliar with the Zebra Puzzle, it is a logic puzzle that was best described by a colleague as a word-sudoku. Here is the version I used, from Life International, p.95, published December 17, 1962:

1. There are five houses.

2. The Englishman lives in the red house.

3. The Spaniard owns the dog.

4. Coffee is drunk in the green house.

5. The Ukrainian drinks tea.

6. The green house is immediately to the right of the ivory house.

7. The Old Gold smoker owns snails.

8. Kools are smoked in the yellow house.

9. Milk is drunk in the middle house.

10. The Norwegian lives in the first house.

11. The man who smokes Chesterfields lives in the house next to the man with the fox.

12. Kools are smoked in the house next to the house where the horse is kept.

13. The Lucky Strike smoker drinks orange juice.

14. The Japanese smokes Parliaments.

15. The Norwegian lives next to the blue house.

Now, who drinks water? Who owns the zebra?

In the interest of clarity, it must be added that each of the five houses is painted a different color, and their inhabitants are of different national extractions, own different pets, drink different beverages and smoke different brands of American cigarets. One other thing to remember: in statement 6, right means your right.

Now that we have the problem, using myself as an example, let us first see how a dev might solve the puzzle.

Organization

Often as developers, we are hit with a lot of information at a time. Being able to keep facts and data straight is key to gaining insights and a clearer picture in which to solve the problem.

In my recent solving of the zebra puzzle, I opted for multiple truth tables, one for each category that had a full mention in the hints. This creates 4 by default, and would exclude drinks and pets. I also added an extra one for expressing variable positions. I then parsed the information from the puzzle and highlighted the facts in green, like so:

The reasoning behind multiple tables is that once the tables are partially filled, not only can I use logical reasoning, but also spatial reasoning. As more information is discovered, the logical blocks in the tables will start to look almost like puzzle pieces. Look at the table now and see if you can see pieces starting to emerge.

While the organizational method I set up is fine, it should be noted that it is not the only way to do this, and the dev being evaluated may come up with a new and ingenious way to organize the problem.

Deduction

Now that we have our facts organized, it is time to start deducing more facts from the information we were given. I do this with a simple deductive logical argument, where two premises lead to a conclusion. Using this form we can infer more information than we started with. Here are the following arguments I used to fill in my tables:

Since, (P1) The Norwegian lives in the first house, and (P2) The Norwegian lives next to the blue house, then (C) The blue house is the second house.

Since, (P1) The green and ivory houses are next to each other, and (P2) the blue house is the second house, then (C) The green and ivory houses cannot be the first house.

Since, (P1) the Norwegian lives in the first house, and (P2) The Englishman lives in the red house, then (C) The red house cannot be the first house.

Since (P1) the first house cannot be Red, green, and ivory, and (P2) the second house in blue (C) The First house must be Yellow.

Since (P1) Kools are smoked in the yellow house. (P2) and the Norwegian lives in the first house which happens to be yellow, (C) The Norwegian smokes Kools.

Now that you have the idea of how that is done, we can deduce that since the Norwegian, doesn’t drink Tea because he is not the Ukrainian, doesn’t drink Milk because he is not in the third house, doesn’t drink Coffee because he is not in the green house, and finally doesn’t drink Orange Juice because he does not smoke Lucky Strike. Therefore, all that remains is Water. So the answer to our first question is that the Norwegian drinks Water.

I’ll highlight facts we gained from these logical arguments in orange.

Integration

The observant among you may have noticed I marked the positions for the ivory and green houses in a mysterious shade of mauve, meaning that based on the inferences so far, we will need to form a theory on where the ivory and green houses go, then test our theory with extrapolation to see if it is valid. I’ll leave this part incomplete for the folks who would like to try to solve the Zebra puzzle on their own.

Evaluation

As you saw above, I broke up the Zebra puzzle explanation into 3 stages: Organization, Deduction, and Integration. Let’s now talk about how we can observe our devs in each stage, and how their behavior might translate to software development work.

Organization is a key skill for a dev - organizing the facts around a problem, handling the inflow of information, creating structures to better serve themselves. When a developer starts the Zebra puzzle you should look for the following:

• Do they write anything down?

• Do they create any kind of structure (like a list, chart, or table) to help themselves?

• Do they keep having to read through the entire puzzle to get the information they need?

A developer who struggles with the organizing stage of the puzzle may struggle with code cleanliness and abstraction, and may end up putting pieces of logic in the wrong places. For example, an error like this would be putting a function that connects to the database in a class that is responsible for rendering views.

Deduction is the reasoning method developers use to cut away irrelevant or trivial information and derive new facts from the information that’s left. Here are the things you should look for when a dev gets to this part in the Zebra puzzle:

• Are they able to reason who drinks water?

• Are they able to explain how they came to their conclusions?

• If they created an organization structure did it serve them here?

In a massive software project, causes and effects aren’t always transparent. A person who has trouble with the deduction portion will most likely have issues deducing why their tests fail or why bugs are occurring.

Integration is the most powerful tool a dev can use. It allows them to form theories based on the facts they have built through deduction. This enables developers to test these theories to deduce new insights and facts.

• Are they able to reason who has the Zebra?

• Can they completely solve the Zebra puzzle?

• Did they trip up and believe something that was false?

A developer who fails the integration part of the Zebra puzzle will probably not be ready to work autonomously, solve complex issues, or perform system integrations. (Yet.)

Remedies

In our evaluation we organized the use of the Zebra puzzle, to identify possible hurdles. We knew that our applicants were unlikely to be triple-threats who were already mature across the board, and we were ready to work with them where they needed to grow. Let’s look at some remedies we can use in our software development process to form that allstar team.

For issues with organization, start by setting a structure in the code and enforcing it. Developers who need extra help can pair-program with a senior during code review. This will allow the senior to demonstrate and thoroughly explain while enforcing the structural boundaries of the code.

For deduction problems, when they eventually (inevitably) get tied up on a bug, start by asking what they have tried. If time permits, point them in the right direction without giving them the exact answer. Another action you can take is going over the domain and possible pitfalls in the code with your team to provide better context when they run into bugs. An example of this would be making your team aware of any caching layer that may be present, as caching errors can often lead to time-consuming bugs.

Finally, and maybe most difficult for the mentor, when a dev is struggling with integration, it is paramount to instill confidence. Since deduction and organization are typically prerequisites for integration, issues in this category tend to come from mentality issues rather than skill issues. Reassuring a struggling dev that it is okay to try things and make mistakes in their local dev environment, and to ask questions, can be meaningful for them. Testing, breaking, and making mistakes is part of the software development process, and can often lead to new premises, which reveal new insights, resulting in further progress.

In summary, the Zebra puzzle can be a fun and useful tool for evaluating new devs, and even a cool exercise for dev teams who may be new to working with each other. If you’re trying to integrate your existing systems or build a software solution, and you want a ready-made all-star team to set you up for success, give us a call.