This might just mean that you've been overly conditioned to expect bad interview questions that do rely on a "trick". But if so, I'm sure you're far from the only person in that position. Would you be less frustrated if it came with a disclaimer, along the lines of "this is not a trick question"?
(I realize this might sound sarcastic, but I'm serious. I think the way interview questions are presented is very important, and often overlooked.)
My go to interview question for the last few years has been kind of similar to this one, in that it's about looking at, exploring, and modifying code that already exists. I also let people look things up, ask stupid questions, etc.
You would not believe how many times I have to tell some people that it's not a trick, I really don't mind if they google something or use `man`. That I'm not trying to trick them into having to know what the arguments of pthread_create are by heart, or that yes they can compile the program in coderpad as many times as they want.
Really unfortunate that so much of the industry thinks interview questions should be like Shyamalan movies.
(also sadly I'm changing jobs soon and I'll have to abandon this question and I don't think it'd fly in the new job's interview policies anyways)
I’ve had plenty of interviews for software engineering jobs where I’ve been asked trick questions. Like “explain why this code is broken” when it’s not actually broken.
I downloaded the code and had a look. For context, I've ramped up on quite a few code bases in my day in a bunch of different languages. Here was what I thought would happen in order of likelyhood:
1. The code would not build at all on a standard linux distro unless you knew exactly what packages to install. (I had an interview like this once)
2. Locking the key was going to be inexplicably linked to the operation (got very worried when I saw `add_delta` and `do_add_delta`). Turns out add_delta just calls do_add_delta wrapping it in a lock. The lock API is very simple.
3. There would be a massive amount of code duplication that would make it difficult to add this feature without doing serious refactoring. Turns out you basically just change `bool incr` for `math_op_t` or something and provide a way to map from binary/string input to math_op_t.
This would be very easy. Depending on how comfortable I was with the editing environment they talk about elsewhere in the hn comments it wouldn't be too bad.
I was waiting to see a weird gotcha about multiplication not being atomic or something. Actually, question for people with more low-level knowledge than me: is that solution atomic?
All math operations on your ordinary everyday cpus are equally non–atomic. They read a value, potentially from memory or from cache, operate on it, and leave the result in a register. Then your program probably has to store the result somewhere, or perform more operations on the result. This is why the memcached software has an explicit locking mechanism; any operation on a cached value involves taking a lock, doing the operation, storing the result, and then releasing the lock.
Multiply doesn't have an equivalent. You can work around that by reading, multiplying and then using CMPXCHG to atomically update the variable if nothing has changed while you were processing. But you need to think about the ABA problem[1]. (I think in this case its safe, but I haven't thought about it enough. Lock free algorithms have subtle bugs.)
Is ABA an issue here? "Replace A by X*A" should be perfectly fine if an atomic swap gives you A back, since it means it was actually A at the time when you perform the swap. That it was B a moment go doesn't seem to matter.
Updating an entry in a database table (which is what a memcache entry is, in practice) is not usually as simple as just "change the value from X to Y". Locking is likely necessary no matter what.
(I realize this might sound sarcastic, but I'm serious. I think the way interview questions are presented is very important, and often overlooked.)