|
|
|
|
|
by crdoconnor
3292 days ago
|
|
"But then, more likely than not, your testing how long it takes someone to learn your stack" It tests how long it takes somebody to learn a small part of it, certainly. Would that not be relevant for a job where you intend for them to learn your stack? "not how well they can solve problems once they're using your stack." A properly structured test could (and, clearly, both of our cases, should) accommodate both - to begin with, the ability to find their bearings in code with which they are not familiar and subsequently to solve problems within that context. I usually do tests like this that last 45 minutes. |
|
>or in other words, total time taken to do n tasks is mn + b, where m is the efficiency when using your stack, and b is the time taken to originally learn your stack. b is relatively large, so with n=1, that's a very different thing than with n=100.
For clarity, I work at google and I'd argue that for all but the most trivial problems, it would take even a good candidate more than 45 minutes to get their bearings. Most new hires do multiple days worth of codelabs before sitting in their desks.