This is a REALLY SOLID response to the question, and I'd hope it would get some strong 'hire' points.
I agree -- but unfortunately the interview question doesn't filter for this level of thinking.
If anything, it filters for the exact opposite: your ability and willingness to shove a random new feature into the codebase in 3 hours (or GTFO) -- stability and other consequences be damned.
You can’t expect every question to give you an opportunity to show off every skill that you have. If I were asked this question, I would certainly comment on whether it seemed like a smart thing to do, but I wouldn’t refuse to do it. I can demonstrate both my ability to do some software archeology, and do some coding, and figure out the design of memcached first, and then also mention to the interviewer that I had reservations about the soundness of the operation. The interviewer may even have more questions to ask along those lines, and might be disappointed in candidates who don’t bring it up.
But they would certainly be disappointed in candidates who don’t take the opportunity to show off the programming skills that they have put on their resume.
As long as we agree that, at the end of the day -- it's basically a crapshoot, as to what you can really tell about the other person based on whether they answer these kinds of questions on time and in as much detail as you like.
That is -- I'm not saying these questions don't tell you anything about the candidate. But at the end of the day ... I just don't think they tell you that much.
Certainly not in the divining-rod, "finally I found a question that will sniff out the true h@ck3rz from the wannabe drudges" sense that people seem to think questions of this sort are imbued with.
> “question that will sniff out the true h@ck3rz from the wannabe drudges”
No one ever said that it would. No single question can tell you everything you want to know about a candidate. This question is designed to weed out candidates who talk well but can’t actually do the work. It won’t tell you which of those passing candidates are great and which are merely good; that’s what the rest of the interview is for.
I agree that interviewing is, unfortunately, a “crapshoot” for the candidates. As a candidate you are going to interact with dozens or hundreds of companies, and most of them won’t do a good job of interviewing you. Most of them end up with more candidates than they can really handle, so they end up passing up plenty of good prospects. But I disagree that this question is a “crapshoot”; it gives you specific information that you really want about each candidate, and it does so without a lot of the irritating artificiality we often take for granted in interview situations.
At the cost of 3 hours of the candidate's time (on top of all the other time demands, and to some extent necessarily irritating artificiality of the rest of the interview process).
Let's just hope the total compensation offered is in line with these demands, then.
A lot of commenters have gotten hung up on the three hours, which I think is pretty funny. As explained elsewhere, it was really just one hour and most candidates did the work in half that. I think that this question fits nicely into a standard interview process, where a candidate spends half a day on site (or in video conference) meeting the team and doing interviews with several people.
Because anyone who has a different point of view about things must be... just all hung up about something or other.
Bottom line is -- if you tell a candidate "this could take up to 3 hours of your time" -- then boom, right there, you've asked them to carve 3 hours out of their life (away from their spouse who may be chronically ill, or who knows what else they might have going), in addition to the all the other hours they need to invest in your process before you can begin to take them seriously.
If that's your process, fine -- just be up front please, and own up to it.
I think you misunderstood. Regardless of what the blog post said, this was a one–hour exercise, not a three–hour project. https://hackernews.hn/item?id=31065845
I agree with you that interviews which incorporate a larger project that takes multiple hours are usually a waste of time. Usually the project turns out to be too unfocused and too subjectively judged to provide useful information about the candidates. I spent four hours on one once where the only feedback I got was that my solution “wasn’t object oriented enough.”
I agree -- but unfortunately the interview question doesn't filter for this level of thinking.
If anything, it filters for the exact opposite: your ability and willingness to shove a random new feature into the codebase in 3 hours (or GTFO) -- stability and other consequences be damned.