Absolutely untrue. In the business world, software developers primary reason for existence is to improve the bottom line. Sure, writing good code for existing business processes is the primary route. But due to our nature of not being encased in the traditions of the departments we are creating applications for, and having knowledge and workings with various parts of the organization as a whole, we get to see a lot more of the big picture in minuet detail than almost anyone else in the company.
Numerous times have I been in situations where no one stopped to break down the problem before jumping to a solution. I've seen people so fixated on a solution that they cost the company hundreds of thousands of dollars for a problem that upon minimal scrutiny became apparent that it did not apply to our organization (hurray for tax codes.)
Users come to us describing a solution to the problem that they are experiencing. We can take their word for it, and hop to on making the solution. But it also presents an opportune moment to get people to wait a second, to look at the business process, and possibly to solve the problem through a minimal change in process as opposed to the creation of a whole new software application.
Pushing the issue in such a way takes a fair bit of self confidence and even a touch of ego. Maybe the original poster was a bit over zealous in his questioning of the problem, maybe he could have questioned the problem in a more constructive way. But the fact that he was questioning the problem, IMO, is the sign of a good developer.
It is a fine line though. And putting up too much resistance or negativity will quickly get your resume round filed.
-Rick
But by giving the problem a context, the interviewer is asking for a much larger answer. In the case of this question, dealing with the most common words in the English language, the consumption of words is likely going to be significantly more difficult and critical to the accuracy of the final product than the sorting and hashing algorithms.
If the goal of the question was to determine the applicants knowledge of sorting and hashing, then the question should have been stripped of context and presented as a purely academic "sort 1 million words by usage." question.
On the other hand, if the goal of the question was to determine how the application approaches a problem, then his act of questioning the problem was a success, although the etiquette of his approach may have been a failure.
-Rick
The last 2 paragraphs of your reply I would agree with :)
Take your abuse elsewhere: I am happy to debate my points but at least bring something constructive.
-Rick
"It's" is a contraction of "it is." You mean "its" -- the possessive form.
Another black eye for you; another feather in my cap!
(Seriously, though. You're demanding tolerance of your cognitive differences -- which is perfectly reasonable -- but also asserting that engineers should approach problems by breaking it into finite automata, GIGO be damned. This strikes me as odd.)
To defend my statement: I explained how I, as an engineer, break a problem down. Pretty much every other engineer I know uses much the same approach (and when I hire I look for the same skill because it fits into our team) - but it's, of course, not the only way. Each to his own.
Seriously: if your going to call out my english at least read and understand what is written ;)
Nit picking over language isn't making a point for you: it'simply suggesting you dont have a decent counter argument. Someone else posted a convincing one - you should give it a read :)
Your a "newish" commentor so I guess you havent learned the culture here :) I made the same mistake once. It's cool no harm done.
First, you're chasing an irrelevant point. My grammatical nitpicking has nothing to do with the topic at hand. I'm writing down "easily distracted by internet arguments."
Second, you're assuming importance. By bringing my "newish"-ness into play you're effectively asserting that hanging out in Hacker News makes you better at arguing your points, which obviously isn't true regardless of how high your karma is. I'm writing down "doesn't actually look up accounts' creation dates before tossing around seniority."
Third, you're assuming ignorance. I have no interest in talking about interviewing policies with you. I am trolling. You have been trolled. Do not feed the troll. I'm writing down "has been trolled."
Fourth, you're chasing the wrong issue. Actually, this is the same as the first trap. I'm not sure why you decided to list it as a separate bullet point. But hey! Traps! Bullet points! I'm writing down "overly fond of bullet points."
Fifth and finally, you're assuming irrelevance. Not in the "making an assumption about" sense of the word, but in the "acquiring the attributes of" sense. I'm writing down "GIGO."
Black eyes! Feathers in caps! Traps!
Wait no i cant be bothered: you've given up the charade so will I.
I know your trolling, it's amusing to feed trolls because (especially round here) it outs them from what they are for very little burn.
The ideal candidate for this job knows when -- as Kenny Rogers put it -- to "hold 'em" and when to "fold 'em." By not simply walking away from a fruitless discussion with a self-admitted troll, you've shown yourself to place pride above the minimax of effort in the pursuit of solution. This single-minded devotion to a stupid, stupid task is not a quality we look for in our engineers.
Instead of readjusting strategies and avoiding the sunken cost fallacy, you chose the classic 6th grade technique of pretending you knew all along and the decidedly modern approach of post-facto appointing yourself as head of Hacker News' Troll-Baiting Brigade (official motto: "We Get Made Fun Of So You Don't Have To," official song: "Nearer To Thee, PG"). When faced with a losing bet, you doubled up.
You can keep the dry erase marker you're holding, but I'm going to have to ask security to see you out.
Hard to find quality candidates these days...
I am a software engineer and I do not work the way you are describing. I take the actual problem to be solved very seriously and try and solve that in the most minimal way possible while leveraging and reusing existing code. I suppose I am not hired because I work differently. I've fallen into your trap of not designing complex systems in a stressful situation the way you expect me to.
So in revenge all my interviews now require a properly spelled and gramatically correct 5k word essay. It's just as arbitrary as what you've proposed. It is my "trap", which is your code word for "unreasonable and inscrutable expectation."
EDIT: as I mentioned elsewhere people do do things in other ways (though you seem to be suggesting my approach might not take a problem seriously??) and there ain't anything wrong with that. At no point did I say there was :)
The problem IS real world though: I can think of several situations in our own company where a programmer would have to manipulate a set of data, find common occurences and order them. Of course each specific problem is complicated by the data and the data source but the fundamental problem stays the same: and so the question IS valid.
The input data doesnt matter (though briefly recognising it is flawed instils confidence).
In terms of your other point about how people write code.. im not 100% sure I agree. As an engineer I break a problem down into I/O machines. Where the input comes from is immaterial so long as it is in a form that is usable. The important consideration is engineering the output.
Your right: he did see the problem with the suggested data set and that is the kind of thing that saves companies money. BUT he hammered that like it was the only issue and (by his own admission) barely considered the actual practical engineering problem. To me that would tell me he is a fairly ok programmer and is bright enough to spot problems - but he is no engineer and I wouldnt hire him :) (that said it is only a small subset of the interview and based on other stuff I have read from the guy I suspect I would find him suitable to hire: he just screwed up the one question)