Puzzle-solving: Not the driving function of software construction

Yeah, I know I promised three follow-on posts after the last one on puzzle-solving interview questions. I’m getting to it. Really. But I wanted to take a minute first and specifically address some of the comments left on the last two posts.Here’s one:

In my opinion, there’s nothing wrong with hiring engineers primarily for their puzzle-solving skills; that’s their primary function.

I’m going to respectfully disagree. A software engineer’s primary job function is to write software, which involves a number of things, one of which looks a bit like puzzle-solving. But the driving function of the complexity and cost of software construction is neither writing software, nor its puzzle-solving component. The driving function of software construction is the collective emotional state of a software engineering organization.

Individual engineers have to be decently smart. Spectacularly smart is even better. But uber smart with a whiny attitude is a no hire. The smartest new college graduate at some university who can’t stay focused for more than three weeks at a time is a no hire. The kid who solves the Rubik’s cube in less than a minute blindfolded but brings other team members down emotionally is a no hire. The brilliant prima dona is a no hire. The defeatist genius who minored in learned victimhood is a no hire. Every single one of these guys can pass the puzzle questions with flying colors. Every single one is a no hire.

Failure to interview for emotional attitude, team play, communication, and can-do attitude ABOUT THINGS OTHER THAN PUZZLES is failure to interview for a successful engineering corps.

But what about division of labor? Why does an engineer have to think big? Can’t the high mucky mucks think the big thoughts and leave the puzzle-solving engineering crew to hunker down?

To wit, this comment:

When you expect or allow those same engineers to decide the direction of the company is when you’re headed for disaster. Large companies like Microsoft and Google can get away with this practice if they balance out their spiffy puzzle-solvers with globally-thinking big-picture people. Smaller companies can’t afford to specialize and compartmentalize their workforce that way and should follow different hiring practices.

Again I’ll respectfully disagree. The notion that there is some clear separation between the engineers in the trenches and everyone else in the company up to and including the CEO is a myth. The collective attitude of an organization, for better or worse, is manifest in everything the company produces, including the products it ships, the ad campaigns it runs, the personality of its sales force, the attitude of the secretary at the front desk, and the code that engineers produce, not to mention the rate at which they produce it.

Personal case study: In 1988 I was a software engineer in the Personal Computer Group at Hewlett-Packard in Sunnyvale, California. I showed up just before HP’s OEM release of OS/2 1.0 for the Vectra PC, and then stuck around to write device drivers for OS/2 1.1. I had access to all the source code for OS/2, which had been jointly developed by Microsoft and IBM. As I cruised around the code for OS/2, it was always immediately obvious which code had been written by IBM engineers and which had been written by Microsoft engineers. In all cases, the coding style was consistent with the collective corporate attitude that you could see on a billboard from a clogged expressway. You could drop code in front of me and I could tell you which company it came from.

Engineering work, even among the most junior engineering staff members, involves creativity and decision making that has nothing to do with puzzle solving. Individual engineers make stylistic decisions about design issues that were not fully clarified by someone outside their team. Attitudinal decisions that affect code maintainability happen every single day. A renegade codeslinger who refuses to follow the corporate style guide has a negative effect that no amount of puzzle-solving speed can repair.

The idea that there is a wall of separation between the puzzle-solving work of the engineers hunkered down in their cubes and the collective vision of the corporation is fantasy. Engineers who can see outside the cube (both theirs and Rubik’s) write code that blends with corporate purpose. They induce a positive ripple effect that transcends their keyboard and compiler.

Conversely, engineers who primarily solve puzzles are more likely to write unmaintainable code, because they don’t see the world from outside their own perspective. They struggle to figure out why all this coding style garbage is being shoved down everyone’s throat. They view sales and marketing as pure overhead, management as the dark side, and software engineers as the only ones around here who do any heavy lifting.

I agree that big picture thinking is absolutely essential for a small company where everyone ultimately does everything. But big picture thinking turns out to also be critically essential for a large company as well.

9 thoughts on “Puzzle-solving: Not the driving function of software construction

  1. It seems obvious that if you are hiring a juggler, a hiring manager should watch candidates … actually juggle (H/T to DeMarco & Lister).

    Similarly, if you are hiring a software engineer, a hiring manager should watch candidates … show high emotional and organizational sensitivity?

  2. @Glade Diviney
    First off, I am going to give you the benefit of the doubt and assume that the first part of your comment is simply restating what the article already make abundantly clear: that you need to see the applicants “juggle.” If my assumption is wrong then I think you missed the point entirely! (see the title of the article if you need help)

    As for your question, you obviously read the first page of DeMarco and Lister’s chapter on Hiring a Juggler. If you peruse a little deeper into the chapter, you will find the answer to your question 🙂

  3. So… Let’s say you have at least 10 people interviewing for a job and you have 20 minutes each. Hiring good devs is notoriously difficult. You’ve said what one *shouldn’t* do, but what *should* you do? Can you weed out all of those no hires in the interview? Most half-way intelligent people know the “right” answer to the behavioral questions and the like. And just as a good coder with a bad attitude is a no hire, so is a positive, great communicator who just learned C last week.

  4. Ask for a code sample. Sure you only have 20 minutes in an interview, but you can spend all weekend perusing code written by your favored candidates. An interview is the only time you get to see personality unedited. Use that to help decide which code samples to actually peruse.

  5. I don’t claim to have all that much experience in the workplace but I just completed an internship at Microsoft and I was pretty surprised at their hiring priorities. I found that, much to my surprise, they were most interested in hiring people who could clearly communicate, even if they weren’t the fastest at solving the puzzles or didn’t come up with the most graceful solution. I found that I worked with very intelligent, sharp people who were also excellent communicators, which is something the company relied on since communication is vital to producing a cohesive product when you have dozens of people working on something.

  6. Pingback: How Software Is Like Biology « Software, Wetware, Webware

  7. Pingback: All I Really Need To Know I Didn’t Learn In Compugarten « Codecraft

Leave a Reply to Christian Bird Cancel reply

Your email address will not be published. Required fields are marked *