[jonchurch_]

Maybe I came into this article knowing too much about the solution, but I dont agree with commenters saying this is a poorly designed interview question. Its a blog post as well, not the format that would be presented to a candidate.

I think it has clear requirements and opportunities for nudges from the interviewer without invalidating the assessment (when someone inevitably gets tunnel vision on one particular requirement). It has plenty of ways for an interviewee to demonstrate their knowledge and solve the problem in different ways.

Ive run debounce interview questions that attempt to exercise similar competency from candidates, with layering on of requirements time allowing (leading/trailing edge, cancel, etc) and this queue form honestly feels closer to what Id expect devs to actually have built in their day to day.

[michaelsalim]

Same here. I thought that this specific problem is not that uncommon. On top of my mind: say if the endpoint you're hitting is rate-limited. It doesn't even have to be an API call. I think I've probably written something with the same pattern once or twice before.

I do agree that this is quite javascript specific though.

[reillyse]

If it’s rate limited it’s handling the concurrency for you. Just back off from the rate limit.

[aidos]

I feel similarly and again.

We actually have this pattern in our codebase and, while we don’t have all the features on top, it’s a succinct enough thing to understand that also gives lots of opportunity for discussion.

[MatthiasPortzel]

I could write a solution to this pretty quickly, I’m very comfortable with callbacks in JavaScript and I’ve had to implement debouncing before. But this interviewer would then disqualify me for not using AI to write it for me. So I don’t understand what the interviewer is looking for.