> Ugh I had someone ask me to debug a verbally communicated error message in an interview. i dont mean that the problem is only verbally communicated. i mean t

> Ugh I had someone ask me to debug a verbally communicated error message in an interview. i dont mean that the problem is only verbally communicated. i mean that the debugging process the candidate does is verbally communicated. in the scenario you're describing you'd be sitting at that machine with access to the internet on another machine. like, you know, in real life. > The problem does a really good job of showing a candidates grasp of all the tricky parts of js, so I keep using it despite the drawbacks. async stuff in js is pretty good, but it's also easy to go too deep on it with some bizzarely poorly architected code. many js devs still fail to grasp all the implications of closures, or how to avoid memory leaks, or how to work with the GC rather than against it.