A candidate not versed in prog folklore = not suitable for hiring

Once again, my thoughts on this matter have been best expressed in a Harry Potter fanfic (http://www.fanfiction.net/s/5782108/18/Harry_Potter_and_the_...):

==============================================================

"Let's try again," said Severus. "Potter, where would you look if I told you to find me a bezoar?"

"That's not in the textbook either," Harry said, "but in one Muggle book I read that a trichinobezoar is a mass of solidified hair found in a human stomach, and Muggles used to believe it would cure any poison -"

"Wrong," Severus said. "A bezoar is found in the stomach of a goat, it is not made of hair, and it will cure most poisons but not all."

"I didn't say it would, I said that was what I read in one Muggle book -"

"No one here is interested in your pathetic Muggle books. Final try. What is the difference, Potter, between monksblood and wolfsbane?"

That did it.

"You know," Harry said icily, "in one of my quite fascinating Muggle books, they describe a study in which people managed to make themselves look very smart by asking questions about random facts that only they knew. Apparently the onlookers only noticed that the askers knew and the answerers didn't, and failed to adjust for the unfairness of the underlying game. So, Professor, can you tell me how many electrons are in the outermost orbital of a carbon atom?"

(Of course Snape knew, but the point stands).

Knowledge of folklore is not an accurate judge of a person's ability by any means. You are effectively ruling out anyone who learned to program in a language other than English, for instance.

But even if English is the language they learned to program in, expecting them to have read the same books as you is silly. There are so many programming books out that there that it boggles the mind to pick any one and expect them to have read it. Worse, to have read it and memorized every algorithm in it.

Programming is about completing tasks, not about memorizing everything in existence.

And this is coming from someone who finds memorization very, very easy, especially when the data to memorize is an algorithm.

I do not know the name Bentley, and I have never heard the phrase "maximum sum subsequence", but given the context in the problem statement, I think I understand what was intended. Seems kinda silly to bring up this notion of "programming folklore".

I was once asked at a job about what OOP design patterns I knew. Design patterns are folklore (and mythology). At the time, I rattled off about three names to satisfy the interviewer, but nobody at my previous employer was busy memorizing names in a random popular book. I admitted as much. The employer hired me (probably not because of my lack of design pattern lingo). The term "design patterns" did not come up in my coursework because it was invented right after I graduated. ;) If a future employer asks me about design patterns, I will happily respond, "Design patterns reveal a language that lacks adequate abstraction features. I do not study design patterns, at least as defined by Fowler and company, because they have no justification in robust software design." Of course, folklore would have it that we should know this answer by now, so we see an example where even the accepted parts of "programming folklore" changes over time.

Conversely, we can think of this as a rather poor filtering technique, because it grants an a nearly automatic pass to anyone who happens to have read any of the popular programming books (or blogs) where the "problem" is presented in easily digestible form, is presented as an "interesting" problem, and it's known that a tractable and optimal solution exists.

A much more important (and deeper) skill is to be able to solve (or reasonably approach) problems they have never seen. And an even more important and deeper skill than that is the ability to recognize algorithmic problems embedded "in the wild" (in naturally occurring business contexts), and to tell the interesting ones from the non-interesting ones (and the trivial from the hard... and among the hard, the plausibly solvable ones from the intractable rabbit holes) without the imprimatur of having someone from a place like Google or MIT telling you that they're "interesting" problems (let alone tractably solvable).

Of course, this kind of skill is much, much harder to test for -- if it can be tested for in the awkward setting of a tech interview at all.

See, this is silly. For me, a candidate who can't ship is not suitable for hiring. All other criteria come second.

programmingpraxis makes a comment in the latest post on Maximum Sum Subsequence:

"any programmer who doesn’t know about the solution will likely fail the interview, on the theory that if he isn’t at least interested enough in his profession to read Bentley [Programming Pearls], he isn’t interested enough in his profession to work for me."

In a follow-up comment:

"I still think a candidate not versed in the programming folklore will be less productive than one who is, and thus less suitable for hiring."

Is this a good or valid criteria for judging a programmer's abilities or future abilities?

Google employs similar practice in its hiring process. The question is, however, how many false negatives you can afford. Google can afford a lot.

Programming Pearls by Jon Bentley had a second edition with updated (for the time) C / C++ in 1999 with the original 14 years earlier. 11 years is a long time in computing and particularly for C++. I have a copy and remember reading it, but I don't remember the example (maybe I didn't find it terribly interesting at the time).

When I think folklore, I think of stories not example problems. I think "Fire in the Valley" not "C Quiz Book".

I may have spoken un-artfully, but there is an important point here that is being missed. I bet that every civil engineer, if asked at an interview, could explain the basic design of Galloping Gertie and the flaws that caused it to fail. I bet that every architect, if asked at an interview, could explain the basic design of the Twin Towers, and discuss why it was less resilient to heavy lateral impacts than other skyscrapers. I bet that every journalist, if asked at an interview, could quote some of the advice of Strunk and White.

As a broad statement, certainly not always true, computer programmers seem to be less knowledgeable of their professional culture than other professions. There is no equivalent to <em>Architectural Digest</em> or <em>Journal of Accountancy</em> or <em>Morbidity and Mortality</em> for programmers, so programmers have to work harder to keep up with their profession. If you can demonstrate that at an interview, you have a leg up on the candidate who can't.

Do you have to know the linear solution to the maximum sum subsequence problem to get hired? Of course not. But if you know it, and the other guy doesn't, then all other things being equal, you get hired, not him.

I should also have mentioned that there must be some context to the programming questions being asked at an interview. There are probably better questions to ask a PHP web developer.

Oofabz: Bentley recounts the history of the problem. Several experienced computer scientists believed for several weeks that the O(n log n) solution was optimal. If you think the linear solution is immediately obvious, you're special.

DannoHung: It may be that I have not fully specified the problem, but an empty sequence has a sum of zero, which is the maximal sum if all elements of the sequence are negative.

Abyssknight: I've never shipped anything. I've always worked in an internal support position, never on a shipping product. But I regularly develop and install new programs for my internal customers, in addition to supporting vendor code; I guess you could say I've shipped those programs.

Goombastic: I'm not a stupid HR guy. I'm a programmer who has stopped asking this kind of programming questions because I don't think they tell me much about the candidate. But it seems other folks do ask this kind of programming questions, so I put them on my blog from time to time.

Everyone: Thanks for the discussion.

Out of curiousity, does any college / university actually have a course in "Computer History", or do we all pick it up on our own?

I am fed up of stupid HR guys coming up with shortcuts/models to the hiring process that just don't work well.

I am not familiar with the book or with this problem, but I thought the O(n) solution was immediately obvious. It's not unreasonable to ask interviewees questions like this. I wouldn't want to hire someone who can't write an efficient algorithm.

I wouldn't punish a candidate for not knowing the answer immediately, but I would expect a good programmer to be able to design algorithms with the requested performance characteristics given a reasonable amount of time.

Fair enough. An interviewer that filters on something as arbitrary as having read the same programming books is not someone I'd be interested in working with.

The linear solution looks like it depends on the maximum subsequence being greater than zero. Is there a similar solution that can produce Integer results?