Async Queue – One of my favorite programming interview questions
86 comments
·July 6, 2025brettgriffin
chis
I think a lot of fields of engineering have analogous questions actually. EEs ask to explain a circuit or draw a new one. Mech Es ask to design some piece of simple hardware with a clever catch. Interviewing is just hard, it’s impossible to cover breadth of knowledge in 45 mins so we end up with little brain teasers.
This particular question is a bit ill formed and confusing I will say. But that might serve as a nice signal to the candidate that they should work elsewhere, so not all is lost.
ThrowawayR2
Lawyers have law school after a degree, a bar exam, legal liability for malpractice, and ongoing licensing requirements.
Medicine has medical school after a degree, a 5+ year residency under close supervision with significant failure rates, legal liability for malpractice, and ongoing licensing requirements.
So explain to us what it is that you "know this for a fact" regarding how they have it easier. Most of the people reading this, myself included, would never have been allowed into this industry, let alone been allowed to stay in it, if the bar were as high as law or medicine.
tkiolp4
The difference is that if you fail medicine, it’s ok (it’s hard). But if you fail to get a job because of the stupid “async queue” author’s problem, well, that’s depressing.
Manuel_D
I'm not so sure. Failing your residency means your medical career is basically done, and you have to basically start a new career from scratch in your late 20s. Chances are you'll have debt from not just undergrad but also med school.
By comparison, failing a leetcode interview means you've got to find a new company to interview with.
glitchc
Perhaps the bar should be as high as law and medicine if we want people to take our industry just as seriously.
FpUser
Nope. In my opinion Wild West in software is much preferred model. If one wants to create software and sell it there should be no barriers. It is one of the the very few fields that give chance to simple people with no money to break out and live decent life.
lmm
> does anyone else get embarrassed of their career choice when you read things like this?
On the contrary, it makes me proud. In private equity, medicine, or law, if you have the right accent and went to a good school and have some good names on your resume, you can get a job even if you're thoroughly incompetent - and if you're a genius but don't have the right credentials you'll probably be overlooked. In programming it still mostly comes down to whether you can actually program. Long may it continue.
esafak
Which part, the fact that you have to answer such questions to get a job? Those other fields are more established and have formal barriers to entry.
brunooliv
Agreed, this is just terrible for the field as a whole it’s like we’re regressing or something
trhway
The higher layer of people in our industry aren’t subjected to those questions. They are evaluated and get jobs more like in law and medicine, ie based on connections and track of record.
Me and you are just not of that high layer. We’re kind of laborers given those simple aptitude tests.
When I was on track to get into the higher layer 15 years ago I got that my last job just by invitation and half an hour talk with VP. Next offer and other invitations came soon the same way, yet I got lazy and stuck at the current job simplemindedly digging the trench deeper and deeper like a laborer.
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.
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.
8note
adding the delay is where it throws me off.
what is the delay actually doing? does it actually introduce bugs into that backend? how do we check that?
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?"
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.)
balder1991
So in the end it had to be funneled to a single server keeping a list of requests to make serially to their API?
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.
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.
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.
evil-olive
echoing the other comments about this being a rather terrible interview question...
> this interview can be given in JavaScript or any other language
it's a language-agnostic question...but it revolves around the assumption of making a callback on request completion. which is common in JS, but if you were solving this in some other language, that's usually not idiomatic at all.
followed by:
> For candidates without JavaScript experience or doing this interview in pseudo-code, you have to tell them that there's another function available to them now with the following signature:
> declare function setTimeout(callback: () => void, delayMs: number): number;
so you add in this curveball of delaying requests (it's unclear why?), and it's trivial to solve...using a function from the JS stdlib. and if the candidate is not using JS, you need to tell them "oh there's a function from JS that you can assume is available"
> After sendOnce is implemented, it's time to make the interview a lot more interesting. This is where you can start to distinguish less skilled software engineers from more skilled software engineers. You can do this by adding a bunch of new requirements to the problem
as you originally specified it, this code is a workaround for a buggy server. and for Contrived Interview Reasons we can't modify the server at all, only the client.
in that scenario, "extend it into a generic queue with a bunch of bells and whistles" is maybe the worst design decision you could pursue? this thing, if it existed in the real world, should be named something like SingleRequestQueueForWorkingAroundHopelesslyBuggyServer with comments explaining the backstory for why it needs to exist. working around the hopelessly buggy server should be roped off into one small corner of the codebase, and not allowed to infect other code that makes normal requests to non-buggy servers.
resonious
I dunno about you, but I spend a good amount of time writing my way around buggy servers that I can't change. It seems pretty realistic to me.
rustystump
I think we all have but that doesn't change that this is almost exclusively a js specific interview question with a very js'y solution to the point of hammering in a imagined "js land" api.
I am not against testing deeper language understanding for a job that requires it but the layers of contrivances to make it "not only js" rightfully rubs non-js devs the wrong way. This comes from someone who loves them some js.
The AI ick at the end makes what would have been mildly interesting, incoherent and uninteresting.
nothrabannosir
for the record (and disregarding how appropriate this is as an interview question): in JS you can (ab)use the event loop and promise chains to do this for you without managing any queues or lists manually. You have a single `let job = Promise.success();` as a global var, and scheduling a new job becomes `job = job.then(f, errHandler).then(callback, errHandler)`. It's a nightmare to debug (because you can't "see" the in-process queue) but it means you don't have to muck around with manual lists, queues, loops, shift/unshift, "isProcessing" flags etc, all of which is basically you reimplementing that native functionality in user space. It completely sidesteps the bug of TFAs naive implementation.
Not advocating for this in prod but in the context of a programming puzzle it can be neat.
late edit: ironically this is also a comment on the LLM talk in TFA: messing with the event loop like this can give you a strong mental model of JS semantics. Using LLMs I would just have accepted a loop and never learned about promise chains. This is the risk in using LLMs: you plateau. If you will allow a tortured metaphor: my naive understanding of SR is that you always move at light speed, but in 4 dimensions, so the faster you move in the 3D world, the slower you move through time, and vice versa. Skill is similar: your skill vector is always a fixed size (= "talent"?). If you use LLMs, it's basically flat: complete tasks fast but learn nothing. Without them, you move diagonally upwards: always improving, but slower in the "task completion" plane. Are you ready to plateau?
bmacho
If you don't care about the order of requests then you can just set up a flag to denote if a task is running, and keep rescheduling the other tasks. Something like
let isProcessing = false;
async function checkFlagAndRun(task) {
if (isProcessing) {
return setTimeout(() => checkFlagAndRun(task), 0);
}
isProcessing = true;
await task();
isProcessing = false;
}
function delayedLog(message, delay) {
return new Promise(resolve => {
setTimeout(() => {
console.log(message);
resolve();
}, delay);
});
}
function test(name,num) {
for (let i = 1; i <= num; i++) {
const delay = Math.floor(Math.random() * 1000 + 1);
checkFlagAndRun(() => delayedLog(`${name}-${i} waited ${delay} ms`, delay));
}
}
test('t1',20); test('t2',20); test('t3',20);
jonchurch_
Nesting at 5 deep increases the timeouts to 4ms! TIL
https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
null
remram
I expected this to be the answer. I guess the interview is not necessarily for JavaScript programmers, but this seems like the correct solution. It brings in some facilities for dealing with errors, too.
odo1242
Honestly that’s not even an abuse of the event loop / Promises. Making a queue like this is literally one of the intended uses of Promises.
thedude14
As a self promoting post I think the author did a good job. As an interview format, I would rather work somewhere less ego driven development and more real problem oriented workplace. But that is just me. Someone could prefer these kind of interviews. I also did a set of questions for java engineers in the past and I always felt there is something really icky. I also noticed the engineers with huge ego revel in these kind of candidate assessments as it makes the feel good, but the candidate performance is poorly tested. Thats what the probation period is for. Just ask the candidate whats his experience. Asking these "cleverly" designed problems is nice for the interviever importance of keeping his job, but is not really usefull. You could even miss a good engineer. Perhaps i see this too narrow and you just really want to observe what the candidate is thinking, but you could make a couple of not really complicated questions and you could see where he is at. I dont bite this head-game at all.
lubujackson
I agree to a point. For me, what chaffs is the convulted prompt that goes against all my instincts for how to design something simply and clearly.
"Ok, but if you had to code something convulted and illogical..." I tend to have trouble with these sorts of black box problems not because of the challenge but because of going down the path feels wrong I would expect my day to day at the company would be surrounded by too clever solutions.
Also, recognize a minimum requirement to solve this under interview pressure is a lot of low-level futzing with Javascript async and timeout details. Not everyone comes in with that knowledge or experience, and it's fine if that is a hard requirement but it seems ancillary to the goal of "interviewing engineers". I can't imagine anyone solving this or even knowing how to prompt AI in the right ways without a fair bit of prior knowledge.
IdontKnowRust
Oh I see what you're doing here...this is just an interview to massage the interviewer's ego.
It must be so boring working you
fastball
How does this interview question massage the interviewer's ego?
dakiol
Here’s an idea for fair interviews:
Interviewer and candidate meet at time X for 1h session of “live coding”. A saas throws at them both one problem at random. Let the game begin. The company can decide if they want interviewer and candidate to collaborate together to solve the problem (the saas is the judge) or perhaps they both need to play against each other and see who gets the optimal solution.
You can add a twist (faangs most likely): if the candidate submits a “better” answer than the interviewer’s , candidate takes over their job.
An LLM could be very well behind the saas.
Oh boy, I wouldn’t feel that nervous anymore in any interview. Fairness is the trick. One feels so underpowered when you know that the interviewer knows every detail about the proposed problem. But when both have no idea about the problem? That’s levelling the field!
yoz-y
Might be a whoosh, but really don’t understand the idea of seeing the interviewer as an adversary. Stress in interviews comes from many places but honestly one of the roles of the interviewer is to bring it down.
glitchc
Why would anyone agree to participate in interviews then? Do we then force developers to conduct interviews? If so, which ones? The superstars or the ones on PIP? You can see where this is going..
billforsternz
> if the candidate submits a “better” answer than the interviewer’s , candidate takes over their job
Corporate life meets the squid games (I quite like it:)
relativeadv
> "This is a good way to test how "AI-native" the candidate is."
yuck
nmca
Why is the method called sendOnce? It’s send with a capacity limiter / semaphore right, so what about it is Once?
charleslmunger
I've implemented multiple production versions of this problem (but not in JavaScript)[1], so maybe my view of this problem is miscalibrated...
This feels both too easy and too hard for an interview? I would expect almost any new grad to be able to implement this in the language of their choice. Adding delays makes it less trivial, except that the answer is... Just use the function provided by the language. That's the right answer for real code, but what are you really assessing by asking it?
[1] https://github.com/google/guava/blob/master/guava/src/com/go...
fastball
You explained how it is too easy, so how is it also too hard?
IgorPartola
It’s funny because I have had ti implement “serialized fetch()” a few times recently, with delays and random jitter too.
I think this question is a bit confusing in its wording even though the concept is actually quite useful in practice. First, async queues have nothing to do with network coms. You can have a async queues for local tasks.
Also while it is obvious to most that you shouldn’t do this, you can also satisfy the requirements to this task by polling the queue and flag using setTimeout() or setInterval(): on invocation, check if there is anything in the queue and if so, if we aren’t waiting on a response fire off the next send().
Retry logic with this system is always a problem. Do you block the queue forever by retrying a request that will never complete (which lets the queue grow infinite in size), or do you give up after some number of retired? If you give up, does that invalidate all queued requests? Some? None? This becomes application-specific. For this kind of thing I have implemented it using multiple parallel queues. That is, you request a send() but using a specifically named queue so that if one queue’s serialized requests break, other queues aren’t affected.
If you do something like `sendOnce(payloadA, callbackA, 5000); sendOnce(payloadB, callbackB, 1);` should payloadB be sent in 1ms or 5000 + RTT + 1ms?
You could solve this in the JavaScript environment by using something like WebSockets or WebTransport much more trivially than by using send() which is I assume a thinly veiled fetch(). This probably fails OP’s interview but in reality leverages the lower level queueing/buffering.
A more fun and likely more illuminating question would be to do something like provide a version of send() that uses a callback for the response and ask to convert it to a promise. This is a really fun one that I had to deal with when using WebCodecs: a video decoder uses callbacks to give you frames but for example Safari has a bug where it will return frames that are encoded as delta frames out of presentation order. So the much better API is to feed a bunch of demuxed encoded chunks to a wrapper around VideoDecoder, and then wait for the resolution (or rejection) of a promise where the result is all the decoded frames at once. This problem really gets at the concept of callbacks vs promises which I think is the right level of abstraction for evaluating how someone thinks of single threaded concurrency. You also can get a really good feel for a person’s attitude here if they refuse to use callbacks or promises (or the async/await sugar around promises).
I'm not going to dive into the specifics of my thoughts on this question. I think a lot of comments here address this.
But does anyone else get embarrassed of their career choice when you read things like this?
I've loved software since I was a kid, but as I get older, and my friends' careers develop in private equity, medicine, law, {basically anything else}, I can tell a distinct difference between their field and mine. Like, there's no way a grown adult in another field evaluates another grown adult in the equivalent mechanism of what we see here. I know this as a fact.
I just saw a comment last week of a guy who proudly serves millions of webpages off a CSV-powered database, citing only reasons that were also covered by literally any other database.
It just doesn't feel like this is right.