Hacker News new | ask | show | jobs
by detinho 1516 days ago
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.

5 comments

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.

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.

Aside from being a lot simpler to use, a dedicated "multiply" command could end up being dramatically more efficient.

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.

That’s not or shouldn’t be a trick question! “An affordance for what I’m asked to do already exists” is an excellent answer. Probably the best answer in most scenarios, and the one I’d most hope/expect to encounter from a “senior”.
The skill of "getting something done without breaking anything" which is basically our profession.
> * 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.

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

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.