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.
Design patterns, at least as defined by Fowler and company, ... have no justification in robust software design.
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?
Design patterns are essentially code that you have to repeat because the language is incapable of generically representing the process that the pattern codifies. For example, I believe pg once observed that most of the classical design patterns didn't exist in any recognizable form in Common Lisp because their functionality could be factored out into higher order functions and macros.
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
Design patterns are essentially code that you have to repeat because the language is incapable of generically representing the process that the pattern codifies.
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.
I agree vehemently. If I am a candidate, the employer's reaction to my answer is part of my employer test. I would experience a certain measure of glee if the employer -- who is testing my technical skills -- had enough technical know-how to ask those kinds of follow-ups.
Yes, in that the presence of design patterns indicates that the paradigm or language used is not sophisticated enough (for example, many if not most of the GoF patterns are unnecessary in Ruby/Python).
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).
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.