Hacker News Reader

This is a REALLY SOLID response to the question, and I'd hope it would get some strong 'hire' points.

But, to be fair, there's already technically this issue in the memcached API as described in the post, in that it supports both append and add, and "append 0" (on a value that add could also act upon) is effectively the same thing as "mult 10". If a field contains "1" and successive "add 1" and "append 0" commands come in, depending on what order they arrive in the result could be 20 or 11.

So I think the interviewer would be justified in saying 'yeah, let's assume we've evaluated that risk and we plan on adding some really thorough documentation warning people about that risk, so can you just go ahead and try and implement it?'

But absolutely, this was the thought that came into my mind when reading the spec too. Not enough developers think about APIs in terms of compositional, algebraic terms, and being able to see that adding 'multiply' and 'add' together at the same precedence in an API might cause trouble is a really valuable skill.

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://news.ycombinator.com/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.”

Fair enough - thanks for clarifying.

Having just gone through this question for fun, the codebase DECR command has this clipping code in it to avoid the value going negative:

       if(delta > value) {
           value = 0;
       } else {
           value -= delta;
       }

A caller reverting operations by sending the same values with the operations flipped around must already keep track that they didn't ask to drop below 0, or they may not get back to the original value.

Plus, the atomic update happens with a lock/release between each operation, so while you might get the same result at the end of your rearranged ordering, clients may see intermediate results and changing the order would change which values they see, which may or may not matter.

I agree it's a great interview question, but I would never ask anyone to spend three hours doing this for free. Someone comes to me and says they can program, and that's that. They have other employers and coworkers in their life, or just teachers and other students -- people I can ask what it's like to work with them if I want, but at the end of the day, I'll know if I've been lied to in the first 30 days and neither of us want that, so I think all I'm trying to find out at the interview-stage is whether I want to spend 30 days with this person, and I don't need to study the outcome of three-hours of them guessing at what I want to help me do that.

But I like to talk about programming, and this question just creates so many different kinds of ideas in my head too. I like how you immediately think about ordering of events and the implications of that. Maybe memcached needs a division operator too. I think that's fun to talk about. Maybe overflows are important; Maybe the task is to add some new types to memcached to protect against that. Maybe we should add some stats to track the number of overflows (or otherwise give some estimate of the accuracy).

Now I am looking at the slide-rule on my desk and wondering what the required precision for the use-case is; That is, is it possible that instead of modifying memcached and having to support your freaky-version forever that you can simply instruct the application to increment by log multiplied out by the desired precision, then reverse with division+exp on output?

And now I am thinking about supportability: Once we've decided what we want out of memcached, is it worth trying to get those changes into the upstream memcached so we don't have to worry so much about that feature disappearing (or becoming difficult in the future)? Talking to people about the social aspects of programming with open-source can be important too.

So yeah, lots of reasons to like this question. I'm probably going to use some variant of it myself, because wherever the candidate goes with it is going to be informative, but I'm extremely disappointed by the rest of the process (and all of part 2); it's definitely not for me.

I don't know the rest of the process, but 3 hours for an interview seems 100% fine. And practical tests are so much better than random abstract questions IMO. I think your solution is to watch and plan on firing many people within 30 days, which seems worse for everyone.

> I think your solution is to watch and plan on firing many people within 30 days, which seems worse for everyone.

Why did you add the word "many" where?

I didn't use it. I can count on one hand the number of people who flat-out lied to me about being able to program and I needed to fire them for it, and I've been managing and developing software for around thirty years or so.

Do you think that's a lot? Or do you think people lying about what they do is common?

> Or do you think people lying about what they do is common?

Probably depends on the offered salary range.

How do you mean?

He/she means that they think people will be more likely to try to lie their way into a job if the salary is higher.

Higher? How much higher? Higher than what? I haven't said what salaries I hire for.

This doesn't sound very much like thinking to me.

Hiring easily with an open mind to firing quickly sounds like a good idea but civil rights law, at least in the US, makes it very difficult. Let's say that "fire quickly" is one of the few women or blacks you've hired. Even worse, let's say that the "fire quickly" contingent is disproportionately women or racial minorities, through no fault of your own. I hope you're ready to pay a lawyer and a decent settlement. It doesn't matter whether you've actually done anything wrong. It just comes down to the economics of the chance they draw a sympathetic judge, the chance a jury will buy their sob story, the amount of money it would cost you to litigate the case, and the amount of money they're willing to go away (i.e. settle) for. Hope no one in your workplace sent a stupid joke over email that will make you look awful in front of a jury. That makes the settlement number go up by a lot.

You can maybe get away with this practice with a small enough company, but even then, I'd advise extreme caution. If you can filter people out before offering them a job, you're in a much safer position legally.

Edit: I think you're in the UK. I don't know much about employment law over there, but I gather the situation is actually better.

> Edit: I think you're in the UK. I don't know much about employment law over there, but I gather the situation is actually better.

I'm in Portugal actually, but I've lived in the UK and the US (I've actually worked there for almost 20 years). In a past life I was hired as the country manager for a British company working out of New York, and I had to receive training on employment law in both the UK and US because they actually take it very seriously in the UK, much more so than in the US; An employee (or former employee) can ask tribunal to decide if their termination was fair, and they absolutely do look for race and gender selection. I can appreciate Americans might not get a very good education on workers rights, so it is perhaps worth mentioning to an American when I fire someone, I'm doing it after I've had that decision reviewed by council, and with that training.

Now when I said they lie to me, perhaps you got some idea that was just my opinion or something. I didn't mean to imply any amount of whimsy and tried to avoid any words that might suggest it; I admitted elsewhere I've fired less than 5 people for lying to me, and that's paper evidence of a lie. I've probably hired hundreds of people at this point in my life, so we're talking about a 1-2% problem where even if we have to pay a six month settlement, that's peanuts compared to what we save:

See, if I had to spend 3 hours for each candidate, and maybe out of hundreds of people I've interviewed thousands, we're talking literal years of my life. I can't realistically do anything else with that time. And not just my life- I have a fiduciary duty to the company I work for, I can't in good-conscience spend the money in the budget for my salary to avoid a much smaller potential penalty that probably won't even happen.

But I think it's important to think about some of the things you're saying: If someone thinks they're doing what I'm doing, and find themselves firing so many people that there is any racial or gender bias in the pool they're firing then I don't think they're doing what I'm doing. I might even wonder if they're racist or sexist myself, because my point is this shouldn't happen often enough to worry about.

The problem is that there's often a gender and racial bias in the pool of qualified workers, but the courts are basically willfully blind to that. Deviation from the overall demographic breakdown is taken as evidence of discrimination, even if those demographic groups have very different breakdowns of qualifications.

I think if you're worried about what a judge and jury would think of something, you probably shouldn't do it.

I'm not worried about firing someone for lying on their CV.

Do you mean "associative" instead of "transitive"?

You are right! This is why I appreciate HN so much. I don't see how to edit my comment but thank you for the correction.

you can only edit your comments for a limited duration, like one hour. Otherwise open the link for that comment (on the date) and there should be an edit link next to the parent link.

This is what experience and skill looks like, careful consideration and really trying to understand what you are doing. Too bad it's so difficult to market this in a superhero genius package that managers will buy

There's another potential issue that may or may not matter - since the value is stored as text it probably can't overflow in memcached - but the multiplication COULD overflow internally in the C code; addition could do this also - I would wonder how it's implemented.