Async Queue – One of my favorite programming interview questions

Scope and Realism of the Problem

• Many argue the setup (a server that “breaks” on concurrent requests, fixed only via a single-threaded client queue) is contrived or “broken architecture.”
• Others note they’ve seen similar constraints in practice: third‑party APIs that allow only one request at a time, low‑limit/rate‑limited endpoints, embedded devices (e.g., Modbus, ADCs) or crappy partner services.
• Several say such constraints are usually handled via a proxy or server‑side queue/rate limiter (Redis/Kafka/DB) rather than pushing coordination into every client.

Ambiguity and Language-Specific Nature

• The question is nominally language‑agnostic but heavily assumes JavaScript’s callback/event‑loop model and setTimeout, which feels unfair to candidates from Go/Java/C backgrounds.
• Some are confused by the term “async queue” for what is basically a serialized FIFO over an async networking API.
• Multiple commenters highlight that the “naive” implementation in the post is logically wrong (nothing ever enters the queue) and that the behavior of send (blocking vs async) is underspecified.

Alternative Implementations

• Many suggest Promise‑based solutions: chaining a global Promise as a simple serialization lock, or using async/await instead of manual queues and flags.
• Others give variants using a boolean “in‑flight” flag plus setTimeout, or treating this as a semaphore problem.
• Some note that Promise‑chaining is idiomatic but harder to debug; others prefer explicit queues as more readable.

As an Interview Question

• Critics:
  • Call it confusing, JS‑esoteric, and too dependent on interviewer‑specific “tricks.”
  • Say it encourages working around a bad server instead of fixing root causes, and tests “reading the interviewer’s mind” more than engineering judgment.
  • See the “add more requirements on the fly” style as ego‑driven hazing and poor at predicting real‑world performance.
• Supporters:
  • Like that it exposes understanding of async control flow, mental modeling of event loops, and ability to evolve a design under new constraints.
  • Emphasize it works well as a conversational, guided problem with nudges, not as a standalone blog‑style puzzle.

Clarifying Questions and Constraints

• There is disagreement on whether asking “why can’t we fix the server?” or “why is it single‑threaded?” is good interviewing behavior:
  • Some see these as excellent root‑cause‑focused questions, as long as they’re brief and then the candidate accepts the constraints.
  • Others see them as time‑wasting in a fictional scenario: in an interview, you should accept given constraints and solve the posed problem.

AI and “AI-Native” Angle

• The article’s suggestion that this is a good way to test how “AI‑native” candidates are draws strong negative reactions (“yuck”).
• Several worry that LLM‑assisted coding can encourage shallow understanding and plateauing, while others still see value in humans deeply learning language internals.

Broader Reflections on Hiring

• Long subthreads compare this kind of puzzle to leetcode and to interviews in law, medicine, and finance, debating:
  • Whether software needs licensure/standards like other professions.
  • Whether technical puzzles meaningfully predict job performance or just select for “professional interviewers.”
• Alternative approaches suggested: code review exercises, debugging a real bug, discussing past projects in depth, or collaborative system‑design and performance‑analysis conversations.