[detinho]

What kind of skill does this type of test measures?

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.

[eyelidlessness]

If I encountered this test, here’s what I’d think (or hope) is being evaluated:

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

[XorNot]

Still winds up just feeling like a trick question: because the immediate response in any real world scenario is "why does the client need this feature?" when a CAS operation is right there.

But probably not what the interviewer wants to hear - maybe.

[avip]

The skill of "getting something done without breaking anything" which is basically our profession.

[jimbokun]

> * 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?

Those things are really the vast majority of programming in a professional setting.

[teraflop]

I'd say your second bullet point encompasses a number of sub-skills, such as:

* 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

[JustLurking2022]

Seems it measures how well you can use shell tooling to code. Personally, I find it foolish to ignore decades of advances in IDEs, so am not part of the cult of "you're not a real programmer unless you use Vim/Emacs". I also find it ridiculous to ask someone to learn a codebase with unfamiliar tooling.