Interviewers rarely ask for the thing they want to know. They ask for something adjacent, cheap to answer, and easy to score, and then they listen to how you got there.
That is not a trick. It is the only practical way to run the interview. The stated question has an answer that is freely available and takes an evening to memorise. The question behind it does not, because answering that one requires having been on the wrong side of it at some point.
Below are seven snippets. Nothing exotic, nothing from a puzzle site. For each one: what gets asked, what is actually being measured, and the follow-up that arrives if you answer only the surface.
Read the code before you read the commentary. It is more useful that way. The method that loses its object
Actually asked: do you know that this is decided by the call, not by where the function was written?
The answer that scores says the binding is resolved at call time from the receiver, and map calls the function with no receiver, so inside a class body (which is strict) this is undefined rather than the global object. Then it says what to do: .map((c) => rates.lookup(c)), or bind it, or make lookup an arrow-valued field so it closes over the instance instead.
The version that only says "you lost the this context" is correct and stops one layer short of where the question was aimed.
The follow-up: and what would the arrow field cost you? (One function per instance rather than one on the prototype, which is fine at almost any scale and worth being able to say out loud.) The loop that is slow on purpose, or by accident
Actually asked: can you tell the difference between sequential-because-it-has-to-be and sequential-by-accident?
Most people say "use Promise.all" and that is where it ends. The stronger answer notices this only matters when the calls are independent, then volunteers the cases where the loop is right: each call depends on the last one's result, or the endpoint is rate limited and firing two hundred requests at once gets you a 429 and a slower total, or you are writing rows that have to land in order.
If you do fan it out, ids.map((id) => fetchUser(id)) and not ids.map(fetchUser), because map passes the index as a second argument and plenty of functions quietly accept one.
The follow-up: two hundred ids. Still Promise.all? (No. That is a concurrency limit, and being able to say so is most of the point of the question.) The Promise.all that leaves money on the floor
Promise.all rejects on the first rejection, but it does not cancel anything. The card charge is still in flight and will still succeed, and you have just thrown away the only reference to its result. You now have a customer who has paid for stock you never reserved, and no handle on the charge id to refund it.
The answer that lands names the state you are left in, not just the control flow. Then it says what you would do instead: allSettled when you need every outcome, sequential when a later step depends on an earlier one committing, and a compensating action for the leg that already succeeded.
The follow-up: what shows up in your logs when the other two reject afterwards? (Unhandled rejections, because Promise.all already settled and nothing is attached to them any more.) The try block that catches nothing
Actually asked: do you understand that catch is about a stack frame, not about a block of text?
processQueue is async and is not awaited, so it returns a promise and the try block completes normally. The rejection arrives later, on a frame that no longer has this handler on it. Adding await fixes it. So does .catch().
This is worth being able to say precisely, because it is the same mechanism behind a catch that misses a setTimeout callback, a rejection inside an event listener, and half the "we have logging and we still cannot see the error" incidents.