You don't have to rely purely on subjective human judgement.
And yet (aside from mega deal-breakers, like clearly overstating competence in some category) that's pretty much what hiring decisions come down to: "Are they for real? Can I rely on them? Will I get along with them?" -- the battery of contrived, essentially "objective" assessment that get thrown at candidates notwithstanding.
What is greatness, you ask? It is the ability of a man to stand on his own, against the whole world, against the very flow of time itself:
Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration.
To be fair, sometimes proficiency in some framework or CMS or vertical skill area does matter a lot more than you think it does. Remember now, the problem isn't that they get candidates who don't know $whatever_niche_topic, it's that they "don't know what they don't know", i.e. they have no inkling that the general "depth of terrain" in that area is much greater than what they were able to size up from their casual acquaintance with it... or that they think they can hit the ground running on a project that a serious heavy hitter with 5-10 years experience in that "niche" area been working on, when of course they can't.
That said, if your interviewers are doing their jobs properly, they should be able to filter for (or simply ask about) that level of skill awareness during the phone screen.
More likely, when you get told post-interview that "we need someone with more experience in X" it's usually a polite way of saying that they just weren't, you know, all the into you, and are trying to save face on both sides by pointing to something dry and objective, rather than things that actually matter. Like you know, the fact that you were underdressed (or overdressed), all those awkward silences you had with that second or third guy you interviewed with (remember, the one who announced his presence in the room by slouching in a chair and saying "I'm hungover"), or that you seemed to exhibit a slight latency in your recognizing some technical term that's common coin in the circles they run in (and so therefore, you just don't have enough chest hair), etc.
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.
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).
That she was "bored" by the exercise doesn't necessarily mean that she doesn't share you and your brother's bold, hard-driving, searingly intense curiosity about the world, and the nature of our ability to infer knowledge about it.
It might, instead, have had something do with the fact that the point you guys were trying to make was rather trivial.
Exactly. Nobody cares if the exact details aren't 100% correct in a non-technical discussion. Suppose I begin recounting a blog entry which describes an odd situation. I may not remember all the details right, but I certainly have the gist of it and can convey that. There is no point in someone stepping in and saying, "you know, it was actually in Des Moines, not Dallas," if the city is entirely irrelevant to actual content of the post.
What is the group supposed to do with that statement? Someone has to segue back to the original topic, while someone else just lost face. Most people will just either ignore the correction entirely, or just drop the topic altogether.
That's cool. Still, it's better form to at least try to not to use language that smacks of category-based discrimination. Just stating your age, for example, will instantly repel anyone in the pushing-30-or-over set.
This is just like any other claim to own some particular piece of real estate: it will have abundant "standing", "merit" and "legitimacy" as soon as she is able to back her claim up by force.
It's been that way since the beginning of time; and (if you follow eminent domain disputes, and the handling of most aboriginal land claims carefully enough), after all is said and done, that's pretty much the way things work nowadays, also.
There are plenty of reasons not to publish on CPAN. Not everyone has time to "babysit" all the modules they write (and deal with people's complaints that they're misnamed, aren't complete enough, etc).
Also, lots of people who were once productive on CPAN years ago have "gone dark" in recent years. Generally has something to do with having a life (fulltime job, family, that sort of thing).
So all in all that's a pretty snarky question to ask. It's definitely a plus to show that you have the sense of civic engagement to go through the full-fledged publishing process on CPAN (including processing testing reports, RT issues, etc) but it should suffice to provide code samples with clean coding style and decent enough documentation (even if it's a well-written README).
And yet (aside from mega deal-breakers, like clearly overstating competence in some category) that's pretty much what hiring decisions come down to: "Are they for real? Can I rely on them? Will I get along with them?" -- the battery of contrived, essentially "objective" assessment that get thrown at candidates notwithstanding.