`

# RETURN ON TECHNOLOGY: Logic puzzles not best way to grade techies

September 19, 2005
KEYWORDS
 Comments Print Reprints / Text Size+

All my life, wellmeaning people have tried to get me interested in chess. It's not like I don't know the game; I do. It's just that it bores me. I tell them I'll take up chess when the rules are changed to allow the queen to conspire with the bishops to have the knights assassinate the king.

Most such games bore me. Card games, even poker, seem insipid. There's nothing at stake but money, after all. Logic puzzles leave me utterly cold. I love to solve problems for clients, and often the harder the better. Even back when I was a humble technician, tracing a problem to its core and then extinguishing it was a joyful experience that made the time evaporate like water from a hot stove. But I don't know if I'd be hired as a technician today, because so many companies are asking applicants to solve silly logic problems in hopes of not making a hiring mistake.

An example is, "You are in a room with three light switches, each of which controls one of three light bulbs in the next room. Your task is to determine which switch controls which bulb. All lights are initially off, and you can't see into one room from the other. You may inspect the room only once. How can you determine which switch is connected to which light bulb?" I'd be tempted to ask the questioner in turn, "Who cares?"

Many of my techie friends solve such problems for fun. I never have. For the most part, any puzzle that doesn't have the potential to solve a real problem for someone is a waste of my cerebral effort, and I simply can't get my mental clutch to fully engage to solve it. I like to really turn a problem around and ponder it from various angles before I commit myself, but many interviewers see that as stalling.

The example I just gave is from the class of "puzzles that have known answers." The interviewer knows in advance what the solution is, so to me it's doubly inane. Much more intriguing is the puzzle that has no real solution, because it more closely parallels the real life of the technical worker. Some solutions are more elegant than others, but the life of a techie resembles that of a golfer, where elegance is less important than getting the ball in the hole. In golf we count strokes, not style points, and in technology we pay off for workable solutions, not just the pretty ones.

An example of this kind of puzzler might be, "How many gas stations are there in America"? There is a right answer, but it's irrelevant; the interviewer just wants to see how you'd approach such a problem. This sort of brain-teaser strikes me as far more valid, and much more interesting than the trick questions.

Indeed, I encounter seemingly simple problems like this all the time when working with clients, and they can keep me up at night delightedly poking at them to see if there's something I've overlooked. How can a user-needs analysis fit into a Six Sigma client environment? How would I simulate a client's scattered user base using only college students? Can 10 text-entry fields be reduced to two without losing data?

It reminds me of the mental game Jerry Markbreit, a highly respected NFL referee for many years and the author of "Born to Referee," played with himself constantly, inventing bizarre football situations and untangling them in his mind. He didn't delight in just any logical messes. Football was his thing, and he spent hours mentally exploring its intricacies.

In the same way, I love business technology problems, and I've been known to talk to the owner of a small shop for an hour or more when all I intended to do was pop in and grab something. His problems with his business technology are often so intriguing that I have to be talked into leaving. Yet, if his problem were presented as a brain teaser, I'd pass.

I even like hearing about others' wacky solutions. An architect designed a heavily visited public building, but put in no sidewalks until the grass was worn down by the pedestrian traffic, showing him exactly where to put the pavement. A science class was tasked to figure out how they would determine the height of a local multistory building, using a barometer. The best answer in my mind was turned in by a student who said he would simply visit the building's owner and swap him the shiny new barometer for revealing how high his building was.

I want that fellow working on my team. Anyone who can find his way so quickly between problem and solution just has to be valuable. And I wouldn't have to give him a mind-bender about lights and a closed room to know that.

Altom is a senior business consultant for Perficient Consulting. His column appears every other week. He can be reached at tim.altom@perficient.com.
Source: XMLAr03000.xml