[reillyse]

I dunno, seems like a really confusing question. Communication is important but I can imagine that explaining this verbally on the spot to an interviewee would not be straightforward especially because the assumptions made around single threading get confusing. If it's just a Javascript question say that - because it seems it basically is. Writing this in go would be super easy so I think the question is just asking people how well they understand Javascript.

[numbsafari]

> seems like a really confusing question

Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.

[gopher_space]

The confusing part for me is why I’m dicking around with the client when the server’s broken.

[MontyCarloHall]

Exactly. If I were asked this question during an interview, the first thing I'd say is "why should the client bother with anything more complex than jittered exponential backoff?"

[Jarwain]

I've had to implement this exact logic at work, because we have to talk to devices using modbus tcp, where a lot of devices only supports having one active request per connection at a time. One device we talk to only supports having 5 active connections to it.

[mikeocool]

FWIW I’ve basically been given basically this exact requirement by a partner with a crappy API.

We’d get on calls with them and they’d be like “you can’t do multithreading!” we eventually parsed out that what they literally meant was that we could only make a single request to their API at a time. We’d had to integrate with them, and they weren’t going to fix it on their side.

(Our solve ended being a lot more complicated than this, as we had multiple processes across multiple machines that were potentially making concurrent requests.)

[layer8]

Because you only control the client, but you need to integrate with that broken server of a third party. It’s a pretty common situation to find oneself in.

[lazyant]

A server that has a spike of load and can't cope with it is pretty normal, hard to characterize as "broken".

When the client(s) can send more work than the server can handle there are three options:

  1 - Do nothing; server drops requests. 
  2 - Server notifies the clients (429 in HTTP) and client backs-off (exponential, jitter). 
  3 - Put the client requests in a queue.

Interview question/solution does 2 in a poor way (just adding a pause), it's part of the client and does 3 in the client, when usually this is done in an intermediate component (RMQ/Kafka/Redis/Db/whatever).

[Xss3]

I implemented an incredibly similar async queue logic for a CLI tool with the option to build sequences of commands

[rustyminnow]

Because it was written in ALGOL 60, none of the mainframe devs are willing to touch that code, and the dozen other clients probably depend on the broken functionality.

[isbvhodnvemrwvn]

That makes it even better, the candidate should ask clarifying questions. I've worked with people who, when encountering some amount of ambiguity, either throw their hands up, or make some random assumptions. Ability to communicate effectively to bridge the gaps in understanding is what I'd expect from any candidate, especially more senior ones.

[dakiol]

But that doesn’t work. One could ask why server can handle only one request? Why can’t we upgrade (vertically or horizontally) the server? Why the logic needs to live in the client? And a large etc.

It’s not the ability to communicate effectively that’s at play here, it’s your ability to read your interviewer’s thoughts. Sure thing, if you work with stakeholders, you need some of that as well, but you typically can iterate with them as needed, whereas you have a single shot in the interview.

Plenty of times, at the end of the interview, I do have a better mental picture of the problem and can come up with a way better solution, but “hey, 1h has already passed so get the fuck out of here. Next!”

[mgfist]

Sure, but this isn't a back&forth interview - it's a blog post. The author could have included a section with clarifying questions they expect the candidate to ask, and responses to those questions.

As it stands, we still don't know why the server was broken in this way and why they created a work around in the client instead of fixing the server.

[trhway]

Absolutely. And it isn’t just about JS, it is about the JS style thinking.

[qu0b]

Yeah, I really don’t see how this is a sensible interview question. It does not even mention async await syntax. Expecting knowledge on callbacks seems dated.