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.

The mistake I see interviewers make is that they are looking for the candidate to solve some kind of puzzle, and the focus is kept on whether they had that "ah-ha" moment vs a clean implementation. Maybe this would be a good approach for a job that required defusing a bomb, but this is relaxed desk work haha.

I once had someone bomb the coding, then email me a few hours after with a clean answer. One of the best hires I ever had.

  const PromiseQueue = {
    queue: Promise.resolve(true),
    sendOnce(request) {
      return new Promise((resolve, reject) => {
        this.queue = this.queue
          .then(request)
          .then(resolve)
          .catch(reject)
      })
    }
  }

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?

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!

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 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.

I’m not sure we’d necessarily get to the part where any kind of solution is proposed, but it would give me a lot of information about what kind of developer culture to expect at this company.

Just by how the problem is presented, I probably wouldn’t want to work for this company. Imagine having to work on real problems with people who demonstrate such poor problem formulation skills.

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.

const lockify = f => {

  let lock = Promise.resolve()

  return (...args) => {

    const result = lock.then(() => f(...args))

    lock = result.catch(() => {})

    return result.then(v => v)

  }

}

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?

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.

Which make the whole coding exercise moot.

What if there are 1 million users opening the browser at the same time?

The queue question is fun but doing it in the client is not right.

  declare function send<P>(
    payload: P,
    callback: () => void
  ): void;

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...

The naming of things is pretty confusing. Async queue, send once, and send many all threw me off and aren't good descriptions for what we are trying to do. I hope this isn't reflective of the company's actual code base. A bit of a red flag.

It also is framed as not a JS question but then the interviewer wants an answer that only makes sense in JS. It also isn't even modern JS. A couple more red flags there.

I dislike questions like this in general, but I've done interviews where they facilitated a decent conversation. It really depends.

It is also just a blog post so hard to infer a lot about the author's actual interview style. Maybe it is great and collaborative. It does remind me of some of the worst engineers I have ever worked with and their interview style though...

Although my implementation doesnt have any sequencing as never had need for it but, more importantly, it has retrying and timeouts. Well retrying I might have implemented on level higher.

Maybe I'm just one of the rare few who actually would have enjoyed this type of question as a chance to brag about my version. Kinda neat as I've never been interested in programming challenges to, for once, know exactly the solution.

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.

Now I must say that I got the vibe from the start they weren't interested in hiring me as much as extracting proprietary quant / trading information from me, but I played along since I was also interested in their culture.

So at the final interview, I get a series of questions that basically The Senate asked Cosa Nostra in https://en.wikipedia.org/wiki/United_States_Senate_Special_C...

And foolish me, maybe, instead of taking the 5th Amendment "I respectfully decline to answer on the grounds that my answer may tend to incriminate me", I foolishly (did I say that again), gave a straight answer. From that on it was only downfall. Watch this movie, it's insightful: https://www.youtube.com/watch?v=TXdC293horg

When you interview, remember, HR and hiring manager are fucking pigs. Anything you say can and will be used against you. So when they ask you of a situation of what you didn't like about your colleagues, you invoke Amendment 5: "I never had a situation where I didn't like my colleagues". When they ask you about how you handled a missed deadline you answer: "I never missed a deadline". And so on. They won't hire you probably any way. No point giving them pigs material to use against you.

Of course on the embedded side you're likely using C, quite likely an RTOS and thus threads, but if you're just using a superloop then you've got a single-threaded system (though with the complication of interrupt handlers) a bit like the interview asks about. I'd probably use a state machine for this with a superloop design, just about everything "async" in embedded boils down to writing a state machine & polling it. Actually writing a fully general-purpose async queue for embedded systems is rather more work, because you'll have to consider how it can be used from within the interrupt context. You really shouldn't block in an interrupt context, so all the queue operations need to be non-blocking. That turns it into something far too complex for an interview question.

Even when you nail the test, it is no guarantee you won't be just wasting your time.

I explain to the recruiter why I am turning down that opportunity and thank them.

Best jobs I had were mainly via my network of friends, or reaching out to engineers directly asking about their companies and open positions, then sharing CV and GitHub, then chatting about technologies used, bugs in production, and other past experiences.

But that server is faulty!! If it has to handle multiple requests at once, it starts to break down.

Ok. I know this is all hypothetical. But I don't buy this premise.

Why is the server faulty ? In what way does it fail ? How do you know it's because it's processing more than one request at a time ? What if there are multiple clients each doing one request only ? Do you have control over the server code ? If so, fix it there!

---

The point is, this solution is fixing the wrong problem and introducing a new one down the line.

If the bug on the server gets fixed, you've now implemented an artificial performance bottleneck on the client.

Devs who know about it are going to leave the org, others are going to try to 'optimize' the code around it with other hacks, since by allowing these kinds of fixes you're building to the wrong kind of culture. Always fix the root issue.

Or change the premise of the problem.

"This is a good way to test how "AI-native" the candidate is."

yuck

I broke down a project I was particularly proud of drawing charts explaining internals.

It was clearly both a test of communication and reasoning skills, but it was frankly kind of fun to answer and put me at ease.

You shouldn't have a favourite question. You need interview questions that create good information signals efficiently. You want the candidate to show off. If they are not strong on async then give them a threading question or something else.

The bug in this implementation is that if sendOnce is called consecutively and the previous request hasn't finished yet, then we violate the "one request at a time" requirement.

Maybe I haven't had enough coffee yet, but the "naive" implementation looks like it wouldn't use the queue at all, regardless how quickly or slowly you fire off the requests.

The code is literally

  if (requestQueue.length === 0) {
    ...
  }
  else {
    requestQueue.push(...)
  }

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.)

What about proxy solutions? IE, proxies that take concurrent requests and serialize them?

The question mainly seems to be working around framework limitations and broken externalities, and the interviewing is providing a signal ("you do not want to work here")

(a lot of people resort to some type of blocking sleep style function call to solve the delay part of this problem)

In many async languages you can do an async sleep (e.g. Python's asyncio.sleep()) which is a sleep that uses the event loop. Really, that's all Javascript's setTimeout() is doing anyway; it's just named differently.

Or you could promisify the send function and use normal async/await.

   let q = Promise.resolve(),
     sendAsync = (p) => new Promise(r => send(p, r)),
     sendOnce = (p, c, ms) => setTimeout(_ => q.then(_ => sendAsync(p)).then(c), ms)

It must be so boring working you

In an interview a candidate is not in that mindset, at least I am not. Under stress and anxiety it is very difficult to fully understand things and build good cognitive structures in the mind.

Can they read code and debug it in their head?

Strong engineers, however, can break out the two problems and solve them at the same time.

Disagree so much with this. A "good" engineer breaks a problem down, solves them one by one, and avoids mentally juggling multiple things at once if possible.

Can you work out the tricks that require this previous experience? If you can then you’re smart if not then you’re worthless.

Just say no thanks and walk out if this is their core way to assess your capabilities.

I understand their argument that they have 1,000,000,000 applicants for every job so it's absolutely totally super required to be like. But companies still paying 2019 wages and are CRUD shops really need to bring it down a notch. You're getting a billion applicants because people are desperate and there are tons of CS grads, not because you're the greatest company on earth

I was informed by the radio firmware guys that a certain kind of request from the host could not be handled concurrently by the radio module due to an unchecked conflict over some global piece of memory or whatever.

I create a wait-free circular buffer for serializing the requests of that type, where the replies from the previous request would kick down the next one.

No mutexes, only atomic compare-swap.