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