On Interview Questions and Sort Routines

So, the responses are coming in on my rant about Real Programmers, and I have to say the responses are disappointing. But what was surprising was what people latched on to, in order to prove that I was, in fact, a “Real Programmer” myself- my aside on my interview question.

There was a reason I picked that as my first interview question. If I’m interviewing you, it’s for a programming position. And the first, and most important, qualification for any programming position is the ability to actually program. I picked a problem that a) everyone who has had any training what so ever has been given a solution to, b) can be implemented in any language, and c) is fairly short. If my walking into the room and going “OK, so you’re applying for a position a programmer- write some code” causes you to panic and freeze up, I’m sorry. But the purpose of the interview is not to make you feel all warm and fuzzy about yourself, it’s to determine whether you’re worthwhile hiring.

And yeah, every once in a while this will cause me to toss back a programmer that should be hired. Guess what? I’ve blown interviews as well. It happens. There are other fish in the sea- on both sides of the table (both other good programmers to hire, and other good jobs to get).

But what really struck me about the responses to this was how unfair it was. It favored people freshly out of college, as one commenter on the original article said. Bwuh? You can’t even remember something as simple as bubble sort? But this was the clue to the heart of the problem, I think.

Those objecting to my post were packers. I’m thinking like a mapper. I want to quote the original Programmers Stone here:

As software engineers, we might describe learning as forming associations between referents. The sky is blue. The rain in Spain falls mainly on the plain. We might call these learned facts `knowledge packets’: little bits of truth (or errors) that we possess.

One can go a long way on knowledge packets. Early learning (as directed by adults) for most children focuses almost entirely on the acquisition of knowledge packets. Things that one should or should not do. Methods for performing tasks. Data to be retained and later recovered on demand.

This is exactly how the respondents were treating the sorting question: as a information packet. A method for performing a task, to be recovered and regurgitated upon demand. This is what made the question favor the newly graduated: they had memorized the prepared answer more recently.

If you believe this- that the reason they taught you sorting back in college was just give you a knowledge packet, you missed the point. What they were trying to teach you was generalized problem solving techniques, and they were just using the specific example of sorting and searching to do it.

Take, for example, divide and conquer- take a complicated part, split it into two smaller parts, solve the smaller parts, and then recombine. This is an incredibly powerful technique, and not only for algorithms. It’s also a real good design pattern- split the big, complicated, unsolvable problem into two smaller problems, and then solve them. This is a principle every programmer should be aware of. Now, apply it to the problem of sorting a linked list: OK, we’re splitting the list into two, and then recombining the two parts, sorting the sub-parts, and recombining. On what basis should we split the lists? If we split the list into the first n/2 elements, and the rest of the elements, then we’ve reinvented merge sort. If we split the list into those elements above or below some given element, we’ve reinvented quick sort. If we split the list into the first element and all the rest, we’ve reinvented insertion sort. You don’t even need to remember the algorithms in particular, if you remember the general principle you can reinvent/rediscover them at speed.

But, of course, if you treat the whole exercise as just a question of storing and retrieving the right knowledge packets, it’s a trick question. Either you’ve memorized the right answer, or not. And that by asking the question, I’m just trying to prove I’m a better programmer than you, on the basis that I know the answer to the trick question and you don’t. When what I’m really trying to do is just see if you have any understanding of programming. And, as of this writing, whether you’re a mapper or a packer.