|
|
|
|
|
|
by jjav
589 days ago
|
|
|
> Just like with a calculator - it's important for candidates to know _why_ something works and be able to demonstrate that as much as them knowing the solution. And this is why I never give coding-puzzle interviews. I just have a chat about your past projects (based on resume). We'll go deep into the technical details and it is easy in such a conversation to get a feel for whether you actually contributed significantly to the things the resume says you did. |
|
|
I’ve been out of work for a couple of years due to complicated immigration reasons, and I was most recently a people manager (although with a few direct technical tasks still). I honestly don’t remember many of the deep technical details of things to which I genuinely contributed significantly as an individual contributor or tech lead, despite those being entirely real and despite me still being a capable hands-on technical person. I’ve had so many jobs recently reject me for reasons like this without giving me a chance to actually demonstrate what I can do.
Memory tests are biased toward people who did the work recently, and biased against people with ADHD (who often have worse long-term memory for such details without being worse hires).
The coding interview shouldn’t be just a blind submit and wait for feedback, nor a live rushed and high-pressure puzzle test (you’re quite right in that regard). Ideally it should be the candidate doing what’s expected to be 1-3 hours of work asynchronously at their convenience within a period of a few days, and then discussing (maybe even presenting/demoing) live in a way that shows deep technical understanding and good communication skills. That avoids conflating memory tests with technical tests. Certain live coding tests can also be okay, but I agree it’s easy to make them unnecessarily uncomfortable with a false signal either way.