[HN Gopher] Async Queue - One of my favorite programming intervi...
___________________________________________________________________
Async Queue - One of my favorite programming interview questions
Author : davidgomes
Score : 71 points
Date : 2025-07-06 16:46 UTC (6 hours ago)
(HTM) web link (davidgomes.com)
(TXT) w3m dump (davidgomes.com)
| dudeinjapan wrote:
| Hmm... this code doesn't work in the real world unless you only
| run it on a single machine. Perhaps a more interesting question
| is how to make a multi-node queue with max N concurrent requests.
| davidgomes wrote:
| The whole point of this interview is that the candidate is
| operating on a single-threaded environment.
| ramon156 wrote:
| These are multiple assumptions "This queue is only on one
| machine and on one thread", what's the real world use-case
| here? Not saying there's none but make it clear. I wouldn't
| want to work for a company that has to think of some random
| precise question instead of e.g. "when would you not use
| mysql?"
| dudeinjapan wrote:
| I guess I don't want to hire candidates who assume the world
| is single-threaded
| jonchurch_ wrote:
| This is handled in the framing of the question:
|
| "... it doesn't ever have to handle more than one request at
| once (at least from the same client, so we can assume this is a
| single-server per-client type of architecture)."
|
| For sure a multithreaded async queue would be a very
| interesting interview, but if you started with the send system
| the interview is constructed around youd run out of time
| quickly.
| reillyse wrote:
| 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.
| qu0b wrote:
| 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.
| numbsafari wrote:
| > 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 wrote:
| 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.
| mgfist wrote:
| 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.
| dakiol wrote:
| 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!"
| gopher_space wrote:
| The confusing part for me is why I'm dicking around with the
| client when the server's broken.
| MontyCarloHall wrote:
| 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?"
| trhway wrote:
| Absolutely. And it isn't just about JS, it is about the JS
| style thinking.
| ZiiS wrote:
| Interviews are a two way street. If you strongly imply that
| working around servers that only do one thing is part of your day
| to day work, a lot of people will want to work somewhere they can
| learn about more modern software.
| armitron wrote:
| This is one of the most confusing and badly worded interview
| problems I've ever seen. If I had been given this problem, I'd
| view it as a signal that I'd be wasting my time working with the
| folks that thought it was good.
| jonchurch_ wrote:
| 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.
| aidos wrote:
| 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.
| ncann wrote:
| > Here's a naive, faulty implementation
|
| For this first implementation, I don't see anything ever added to
| the queue. Am I missing something? New task is added to the queue
| if the queue is not empty only, but when the queue is empty the
| task is executed and the queue remains empty so in the end the
| queue is always empty?
| JohnKemeny wrote:
| That's how I read it too. Nothing is ever added.
| Arch-TK wrote:
| That's correct.
| bluelightning2k wrote:
| Interestingly I think I would over-think this. The interviewer is
| assuming a single server, running in a VPS type environment.
| There's also no notion of state persistence/timeout/recovery etc.
| I think I'd immediately have started factoring those things in.
|
| ALSO while JavaScript is a single threaded environment, the while
| solution would still basically work due to the scheduler (at
| least if you yield, await sleep, etc.)
| jnettome wrote:
| thanks for sharing and by reading the blogpost and the comments I
| think I get the whole point: it's all about how engineers
| understand the requests and the reasoning about how does it
| approach that more than the code itself. If this raw code really
| works or not it's almost secondary here - IMHO nobody I'll start
| coding a real queue out of blue like this.
| comrade1234 wrote:
| Do I have to use JavaScript? I'd write it in Java in a way that
| it would be trivial to ramp up the number of connections in the
| pool once they fix their stupid server.
| 4ndrewl wrote:
| Definitely one of those where the interviewer wants to show how
| smart they are.
| IdontKnowRust wrote:
| 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
| thedude14 wrote:
| 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 wrote:
| 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.
| lordnacho wrote:
| The explanation is way too long, in an area that is pretty big
| and can be done in many ways. Couple this with candidates who
| will variously be fearful of asking to many or too few questions,
| and you just have confusion about who is good and who is not.
| nothrabannosir wrote:
| 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?
| brettgriffin wrote:
| 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.
| brunooliv wrote:
| Agreed, this is just terrible for the field as a whole it's
| like we're regressing or something
| esafak wrote:
| 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.
| ThrowawayR2 wrote:
| 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.
| rubyn00bie wrote:
| I'm really confused why this is an "async queue." Seems pretty
| synchronous to me since requests are completed in order, one at a
| time. I literally wrote something to do this in the past few
| months. This was to work around JavaScript's asynchronous IO
| making a shit show of updates from library being used in the
| client. I had to queue requests in JavaScript, have them execute
| in order (FIFO), and explicitly described it "synchronous."
|
| Is it only "async" because it's doing it in JavaScript and the
| underlying network request API is asynchronous? Seems like, IMHO,
| a really bad way to describe the desired result since all IO in
| JavaScript is going to be async by default.
| dakiol wrote:
| I don't know anything about the author, so just speculating here:
| assuming that the interview lasts 1h, it's not realistic (nor
| fair) to judge the candidate's answer if the interviewer has
| spent more than 1h to think about the problem and potential
| solution(s).
|
| Interviewers have thought about the problem they propose
| countless of times (at least once per interview they have hold)
| each time refines their understanding of the problem, and so they
| become god of their tiny realm. Candidates have less than one
| hour, add to that stress and a single shot to get it more or less
| right. You're not assessing candidate's ability to code nor their
| ability to handle new requirements as they come.
| dakiol wrote:
| 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!
___________________________________________________________________
(page generated 2025-07-06 23:00 UTC)