Comment by cafxx | Hacker News Reader

Comment by cafxx | Hacker News Reader

Parent Full thread

> Via its incr and decr commands, memcached provides a built-in way to atomically add k to a number. But it doesn’t provide other arithmetic operations; in particular, there is no “atomic multiply by” operation. Your programming challenge: Add a mult command to memcached.

Protip for people in junior roles: if you're interviewing for a more senior position, the correct answer would *not* be to jump in straight and waste 3 hours implementing something that then you have to maintain forever.

The best answer, from an *engineering*[1] perspective, would instead be noticing (or knowing) that memcached supports a CAS command (https://github.com/memcached/memcached/wiki/Commands#cas) that would allow to implement equivalent functionality without changes in memcached, and try to confirm why that would not be a viable solution. If, and only if, CAS is confirmed not to be a viable solution (e.g. excessive contention, unacceptable pX latency, ...) then you should spend the 3 hours (+ all the maintenance effort required until the end of life for that solution).

The risk, in case you jump acritically on the solution, is to show you did not spend any time trying to actually understand the problem and you did not consider the pros and cons of viable alternatives (and this is a problem both during an interview, as well and especially when you're doing actual work), something that is normally frowned upon in senior roles.

Obviously, being an interview, it's all play pretend so you'll eventually have to complete the coding exercise, but if I was interviewing you for a senior position and you skipped the part above it would be a pretty big red flag (same in the unlikely case I were to ask to implement some functionality that is commonly found in the standard library of most programming languages: huge red flag if you don't ask why the functionality provided by the standard library is not a viable solution).

[1]: w.r.t. software engineering being "programming integrated over time" (https://adamj.eu/tech/2021/11/03/software-engineering-is-pro...)

During interview, we are not modelling the whole process -- no one would tell a senior engineer just a single sentence "please implement mult command" -- there will be a longer preceding story: maybe the latency has to be very low, or it is a request from a stubborn customer, or you are profiling optimization... So for the reasons of time, we assume that the previous steps have been done, and it was decided that the mult command is the way to go.

If I were interviewer and a candidate would mention CAS command, I'd compliment them for their memcached knowledge, and tell that the it is not a viable solution. And this would not affect my evaluation of this stage one way or another.

> So for the reasons of time, we assume that the previous steps have been done, and it was decided that the mult command is the way to go.

That's the mindset that leads to a crippled code bases. One should always question the methods that arrived to a potential solution. Ideally before spending hours implementing and years maintaining said solution.

I'd hire a candidate that thought outside the box with CAS on the spot, they offer more value overall than a Get It Done fast coder ever will.

Sure, but while I would mention that while talking over the question, I also wouldn’t turn up my nose at the chance to show off my programming skills. This is an interview, after all.

> no one would tell a senior engineer just a single sentence "please implement mult command"

It definitely happens (at least it did to me) to be given programming tasks without context. Maybe my comment wasn't crystal clear on this, but I was not providing advice for interviews to the specific company mentioned in the OP, rather general advice for senior roles. In this case the claim that "no one would tell ..." is hard to maintain.

> this would not affect my evaluation of this stage one way or another.

Same point applies here. We all know different interviewers have different ways to evaluate. Therefore it's helpful to cover your bases. Hence my comment to not skip that part. For some interviewers it won't matter, but for others it will be a rather important factor.

> and tell that [...] it is not a viable solution

Just for the sake of discussion: if I were the interviewee I would then definitely ask why it's not viable, and if I did not get a satisfactory answer it would for sure affect my impression of the process and, by extension, of the company I'm interviewing for. Not claiming that every interviewee is like this, just that this is the case for some (I am simply not pretending to be an exception on this).

I would hire the guy who notices the CAS in the protocol rather than the one who forks memcached, creating a maintenance burden, and potentially introducing safety or liveness issues (although memcached is somewhat simple, most databases are not, especially distributed ones, bring your TLA+).

And memcached isn't going to pull your changes either, because they want a simple protocol. It's not a CRDT-oriented project.

CAS is the correct approach. inc/dec are ok for counters but that's that. I didn't know anything about memcached - yet atomic w/o knowing the original value is an absolutely pointless operation. CAS (as in CPU compare-and-set/swap) is a universally useful approach.

Reply on news.ycombinator.com