I think the main ones are:
* How much about the language the candidate knows. Not the control flow and data types, but how to navigate and where to look for information. And that leads to bellow
* how quickly one can understand a codebase (at least part of it) and start delivering
What else?
If that's one of those "think out loud" tests it's possible to get a clue of how the candidate thinks, but it's not specific of this test.
- Do you understand the problem, or seek better understanding if not? (Obviously the problem here isn’t extrapolating arithmetic, but identifying the importance of an atomic operation.)
- Do you recognize the value of the change, or question it if it feels non-obvious?
- How do you think about approaching an unfamiliar codebase/code path?
- How do you think about the challenges you encountered while working on the problem?
- What else felt important to you that I’m not looking for?
All of these questions provide a lot more information than “can you write code?”
Especially meaningful for evaluating actual fit is reactions to walking into pre-existing code. In fact I think this has been, at least subconsciously, my best heuristic for assessing colleagues’ skill maturity. “Juniors” will stare at a problem or ask a lot of easily answered questions; “mid level” devs will bang their heads trying to answer without asking; “senior” devs will have a good intuition for which challenges are discoverable and which are best solved by asking a human or a google or whatever, or at least for recognizing the distinction after some time exploring the problem.
But probably not what the interviewer wants to hear - maybe.
If multiple clients are simultaneously trying to update the same value, then locking allows them to take turns with relatively little overhead. With compare-and-set, all but one of the clients would fail at the "compare" step and need to retry, requiring additional network round-trips.
Those things are really the vast majority of programming in a professional setting.
* Understanding common coding patterns, and inferring design intent from them
* Quickly prioritizing "critical" vs. "nice-to-have" components of a desired feature (and reprioritizing as you learn more about the implementation constraints)
* Being able to take a partially-complete or slightly buggy implementation, and quickly identify what's wrong with it (e.g. by interpreting compiler errors or using a debugger)
* Gaining confidence in the correctness of code by spending a reasonable amount of time on testing, without going overboard