This is not the worst interview question I have seen, but it sure could use some improvement.
The naming of things is pretty confusing. Async queue, send once, and send many all threw me off and aren't good descriptions for what we are trying to do. I hope this isn't reflective of the company's actual code base. A bit of a red flag.
It also is framed as not a JS question but then the interviewer wants an answer that only makes sense in JS. It also isn't even modern JS. A couple more red flags there.
I dislike questions like this in general, but I've done interviews where they facilitated a decent conversation. It really depends.
It is also just a blog post so hard to infer a lot about the author's actual interview style. Maybe it is great and collaborative. It does remind me of some of the worst engineers I have ever worked with and their interview style though...
I think also trying to work around a faulty server with client code is a bit weird, I could see it happening in practice but my first instinct given this interview would be to insist the server should receive some attention first, or if it is impossible at least this queue should be implemented by another process or machine near the server side.
I agree this could work if framed as a coworker rubber ducking his problems to you and asking for ideas to get to a solution, because it could clear up the naming issues and focus on the candidate solving problem skills without the pressure about giving the one right answer to the problem.
The naming of things is pretty confusing. Async queue, send once, and send many all threw me off and aren't good descriptions for what we are trying to do. I hope this isn't reflective of the company's actual code base. A bit of a red flag.
It also is framed as not a JS question but then the interviewer wants an answer that only makes sense in JS. It also isn't even modern JS. A couple more red flags there.
I dislike questions like this in general, but I've done interviews where they facilitated a decent conversation. It really depends.
It is also just a blog post so hard to infer a lot about the author's actual interview style. Maybe it is great and collaborative. It does remind me of some of the worst engineers I have ever worked with and their interview style though...