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