Array sorters aren't problem solvers

The evergreen problem-solving

If you work in software product development like me, you hear a lot about problem-solving. Problem-solving skills, problem-solving attitude, problem-solving interview steps.

What most companies call problem-solving has nothing to do with actual problems, though. And the interview steps aimed at testing a candidate’s skills at this? They’re completely off the mark. As a candidate, you typically get 30 to 45 minutes to complete a coding task, which usually involves sorting arrays, inverting binary trees, or achieving something trivial under some made-up limitations, like implementing the multiplication operation.

So what’s wrong with these questions? Are these not problems? Not at all, they’re exercises.

Problems vs exercises

An exercise is always devoid of context, static, and timeless. It’s something you can analyse and work on in isolation, and it’s immediately obvious whether a potential solution works for an exercise.

Problems are a different story. An example of a problem might be “why do we keep producing so many bugs, irrespective of all our efforts and of how much the CEO cares about this?” Problems are messy, and always come with a lot of context, ambiguity, and related problems. It’s not clear whether a candidate solution will work, or whether a solution exists at all.

Successful problem-solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem. Our ability to solve problem is limited by our conception of what is feasible.

Analysis works well for exercises:

1. You break down the exercise into its constituting parts.
2. You recursively analyse the parts.
3. You find how to make each part of the exercise work.
4. You put the parts together and, voilà, your exercise is solved.

Synthesis is much better suited for problems:

1. You look at the containing system the problem manifested itself in.
2. You recursively look at the containing systems e.g. the team, the department, the company, the market, the city, the country, the industry.
3. You understand why the problem manifested itself in the existing system.
4. You redesign the system so that the problem cannot manifest itself: you dissolve it.

Redesigning and changing a system are problems themselves, so you never know what will work. Two companies might require a very different approach to solve the “same” problem.

The state of the industry

So what’s the big deal? Well, it’s that array sorters are not problem solvers. And being able to sort an array in 20 minutes, or implementing Timsort by hand on a whiteboard, says absolutely nothing about your ability to solve problems. If anything, people who obsess over exercises tend not to do so well with problems.

No company ever went bust because their development team couldn’t sort an array. No customer refused to renew their subscription to a company’s product because people couldn’t invert a binary tree. In comparison, plenty of companies died because they could not solve the social dynamics between their founders, or because they allowed entropy to grow too much and ended up having to run just to stand still.

Why do companies insist with exercises then? Because in a world that loves pre-canned, microwavable solutions, understanding and wisdom are often dismissed as wanting to overcomplicate things. Because you cannot appreciate things you don’t understand, and understanding and wisdom are an exception.

And because, if you can’t design a real-scale Twitter in 40m, you clearly won’t be able to move JSON objects from the company’s web app to the company’s database and back.