"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).
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 don't think it's meant to be universally applicable.
I'm only situationally in favor of this kind of thing, and I'd rather be a footnote/tilt factor than an actual bannable issue in a hiring process.
I've got a cursory familiarity with unix/hacker culture, but I don't think I would pass a Google-interview-esque history lesson even if I was able to ace that programming language test that went around earlier this week.
I think it's worth mentioning here that there are no accurate methods of measuring competency in programming save for actually battle-testing them.
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.
I don't particularly venerate the concept of design patterns, nor would I bother asking about them during an interview. But could you justify this statement?
Ah, I found it. It was in his Revenge of the Nerds essay, and he was actually citing Norvig, though he goes into more detail than just that. http://www.paulgraham.com/icad.html
Also, Coding Horror on the topic: http://www.codinghorror.com/blog/2005/06/are-design-patterns...
In the specific case of the twenty canonical design patterns from the GoF book, some are rendered trivial by better languages, but the principle of a design pattern remains valid. I'm confident that Lisp has design patterns, I own a book full of them:
A design pattern in the abstract is a systemized form of folklore. Problem Statement, Forces Acting on the Solution, Template for Implementing the Solution. Until we have a language where every problem to be solved can be done so with a single atomic element of the language, there will be design patterns that programmers use to share their experience.
Now that we have established that we can choose several different colours for the bike shed, I will say that if you gave me that answer in an interview, I wouldn't hold it against you in any way. It demonstrates intelligence and experience. I imagine that if we were talking face to face we could have an interesting conversation about languages and abstractions and templates and problems and communicating folklore.
So my meta-observation is that the important thing about a question is whether it helps provoke an interesting and useful conversation, not whether the person parrots out some answer you are seeking.
On the other hand, some people still have to work in such environments so it is good for them to know the patterns, and it may be beneficial for others to understand them as well (as foundational structures).
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.
Every time after that, they could be boiling your code into a morass of blood, sweat and Jolt, weaving the Cthulhu pattern around your other Engineers' souls.
Ultimately, if you hire someone who ships, makes your code awful, pisses off your other engineers, doesn't document then chuffs off leaving you with a turd of an app and no-one to work on, their shipping only bought you N releases. A better engineer might have bought you <N releases... But prepared you for >N in the future.
"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?
While Programming Pearls is a reasonable test -- akin to checking whether someone has a classics background by asking a question about Moby Dick -- it should be acknowledged that everyone has some holes in their background, possibly even glaring and regrettable ones. A better question might be, "Describe a favorite clever hack and where you read about it."
I do outside reading, but I would be hard-pressed to make this claim. How is outside reading correlated to research ability? This is like saying, "If programmers are not playing a musical instrument outside of work, then it is obvious they do not have what it takes to think in patterns and perfect their skills."
When I think folklore, I think of stories not example problems. I think "Fire in the Valley" not "C Quiz Book".
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.