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).
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.