Measuring the hypotenuse

Consider the following right-angled triangle:



What is x? Not a trick question.

Well it’s 5. Obviously.

But how did you know that? Well maybe for this very simple example you happen to just remember that 3:4:5 are the proportions of a right-angled triangle. But given a non-trivial example with less straightforward lengths to the two known sides you would doubtlessly have employed Pythagoras’ Theorem. Certainly that’s what most people would expect to see if they presented you with such a problem.

There is of course another way. Assuming the diagram is to scale you could measure x.

But that’s not what people would expect; especially if they’d ask you to use math to solve the problem.

In previous blog posts I’ve described a programming problem I set interview candidates at my organization.

The coding exercise I set people is pretty simple. It draws its inspiration from the old text adventure games the likes of Infocom and Level 9 used to produce. If you’re not familiar with this genre the basic gist of them was that there was an unexplored territory that you could wander around with things to find and puzzle to solve. Players interacted with the game using simple text based instructions such as “go north, get axe and kill troll”.

The exercise requires the candidates to do nothing quite so complicated as that though. They simply get an XML file describing a simple collection of rooms connected in various ways and containing various objects plus a text file describing their starting location and objects they need to go find. Their task is to write a program to read the two files and then use some approach to wander through the maze and try and collect the items.

Just as you would expect something to use Pythagoras’ Theorem to find x in the problem above I would expect people to use some kind of algorithm to solve this programming exercise. I don’t care if the algorithm is as dumb as a stumbling drunk, randomly staggering from room to room until every item is found or if you’re using something like Djikstra’s shortest path, just so long as there’s some kind of intelligent solution for us to discuss.

Up until now nobody had disappointed with that expectation either. Just recently though I got a very novel submission. What the candidate had done, rather than algorithmically solve the problem was to simply issue a series of printed lines that simulated what the output might look like if they had done the exercise for real. In other words their “solution” basically was:

Console.Write("At Sculery: lamp\n At Dining Rome: plate\n At Pond: Fishing Rod\n At Library: book\n At Cave-Entrance: Pickaxe\n At pine Forest: Pine cone");

I hunted around for a bit in case there was more. Alas there was not. When I was trying to explain to the recruiter involved why there was no point proceeding further with the candidate I came up with the hypotenuse measuring analogy which he got completely.

Although I’ve never seen anyone else “solve” the programming exercise in quite this way, regrettably I have seen others who approach problems similarly, trying to find any and all obtuse approaches to avoid actually coding what’s really needed. A common variation on the theme is mangling unit tests in perverse ways to avoid actually testing what you should be.

Since this isn’t an isolated phenomenon I decided I’m coining a new term to describe it. Henceforth (for me at least) programming “solutions” that completely miss the point will be known as a “measuring the hypotenuse” approach.