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.

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.

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.

When all around me in this FAANG type role are engineers giving leet code esque questions, I was trying to be a breath of fresh air for them.

Sadly, I need to rethink this now, because you can throw it in an LLM and it'll give you a nearly complete answer. I've already had one candidate clearly do that.

They become hotbeds of intellectually rich but functionally and productively inept individuals who value spending resources indulging in esoteric side quests instead of driving businesses forwards in ways that are 'just sustainable enough'.

I've always been on the periphery of FAANG 'level' situations trying to focus on the surface where tech and humans meet and as the 3 decades of my career have gone on, software engineering has become more and more ludicrous and bubble like to the point where it, and the developers working on it, are now just the annoyance between me and my goals.

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.

But all the "ok, now add this feature..." stuff is just a sign that the interviewer is an insecure asshole. And you get insecure asshole interviewers in other professions as well, asking about obscure laws or diagnoses.

Software is still a bit of a craft, and it's perfectly reasonable to ask a job seeker on a construction site to go hammer a nail. But nobody is going to follow that up with a bunch of "OK, now do an L-joint" just to show off their own knowledge.

What specifically is embarrassing about it? None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work. They're also fairly discussion based rather than having one silly trick answer (like the XOR trick that came up recently here). The whole point of an interview is to check that the candidate can do their job. What would you propose instead? We don't bother to interview and just cross our fingers and blindly hope they'll know what they're doing?

I can only assume that the real reason for your objection is that your job actually doesn't involve solving problems like these ones. Well, that's fair enough, and then I'd expect the interview for your position to look different. But why would you assume that there are no jobs that really need these skills?

Your comment about using a CSV file for a database seems unrelated. Maybe I missed the real point of your comment?

I know the feeling.

The author says this is one of their favourite interview questions. I stop to wonder what the others are.

When I'm interviewing a candidate, I'm trying to assess really a few things: 1) the capability of the person I'm interviewing to have a technical conversation with another human being; 2) how this person thinks when they are presented with a problem they have to solve; and 3) can this person be trusted with important work?

For 1) and 2), coding interviews and the types of artificially constructed and unrealistic scenarios really aren't helpful, in my experience. I care a lot less about the person being able to solve one specific problem I hand them and I care a lot more about the person being able to handle a much more realistic scenario of being hand handed an ill-defined thing and picking it apart. Those conversations are typically much more open-ended; the goal is to hear how the person approaches the problem, what assumptions they make about the problem, and what follow-ups are needed once they realise at least one of their assumptions is wrong.

This is a really hard thing to do. For example, I imagine (but do not know) that when a medical practice hires a doctor for a certain role, there is an expectation that they already know how the human body works. For an ER doctor, you might care more about how well that person can prioritise and triage patients based on their initial symptoms. And you might also care about how that person handles an escalation when a patient presents not too awfully but is in fact seriously ill. For a GP, it's probably more important for a practice to care more about healthcare philosophy and patient care approaches rather than the prioritisation thing I mentioned above. I'm spit-balling here, but the point is these two situations are both hiring doctors. You care less about what the person knows because there is a tacit assumption that they know what they need to know; you're not giving the candidate a trial surgery or differential diagnosis (maybe... again I'm not a doctor so I don't actually know what I'm talking about here).

If I'm hiring a software engineer or performance engineer, I am trying to figure out how you approach a software design problem or a performance problem. I am not trying to figure out if you can design an async queue in a single-threaded client. This problem doesn't even generalise well to a real situation. It would be like asking a doctor to assume that a patient has no allergies.

Item number 3) is "Can this person be trusted with important work?" and this is basically impossible to determine from an interview. It's also impossible to determine from a CV. The only way to find out is to hire them and give them important work. CVs will say that a candidate was responsible for X, Y and Z. They never say what their contribution was, or whether or not that contribution was a group effort or solo. The only way to find out, is to hire. And I've hired candidates that I thought could be trusted and I was wrong. It sucks. You course-correct them and figure out how to get them to a place where they can be trusted.

Hiring is hard. It's a massive risk. Interviews only give you a partial picture. When you get a good hire it's such a blessing and reduces my anxiety. When you hire a candidate you thought would be good and turns out to be an absolute pain to manage it causes me many sleepless nights.

And as a doctor, you can't attend a 4 week bootcamp, call yourself a doctor and inflate the ranks of desperate looking for a job. And at least you gotta be in person, no remote.

Much of the problems of software engineering stem from the highly inflationary nature of it's people. There's a trillion of us already and more keep coming. That's what you get when there's a dozen for everything: a dime's worth.

1) Scope - Other fields like law, medicine atleast are impacting one unit at a time, vs software which is impacting large number of users through your work. I am sure research interviews will go through similar process?

2) Feedback - Just basis past work, you would get a good sense of their aptitude. Very hard to do it in programming without you spending a lot of time going through their work?

3) Subjectivity - Wrt coding, very good way to get objective output in interview by getting other person to write code, can't do that in medicine for example?

Most Mechanical / Electrical / Civil Engineers have formal accreditation processes, too.

IT is something of a clusterfuck but even there we have things like CCIE or RHEL or Windows Certs that can prove a minimum level of competency.

The lack of regulation makes it easy for anyone to be a dev but also means there is no formal minimum standard.

No.

> there's no way a grown adult in another field evaluates another grown adult …

There is. Demonstrating competency over a common and interesting problem is the baseline.

Are queues commonly needed? Yes. Is task processing commonly async? Yes.

Fantastic, then what precisely is the problem?

What is most puzzling to me is that people are confounded when even low standards are set for each other. This isn’t a high bar.

Haven't had any major issues hiring this way, but I did reject people that appeared to be full-of as your said, or didn't have anything public on github/company gitlab/dockerhub/researchgate/etc.. With exceptions for entry level positions and a few that worked in research or govt where work couldn't be made public (they still normally have some participation in research publications, conferences, technotes, etc.)

I like to hear candidates explain how they understood and met the customer's requirements. The code is only part of the success.

Priorities are often different with experiments and side projects.

I also think why someone built something can be more meaningful than how.

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

I literally had to implement this exact queue mechanism because of a 3rd party integration with an uncooperative server

it's a pretty real problem

Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.

I do agree that this is quite javascript specific though.

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.

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

Plus we have a case where a certain type of request should skip to the front of the queue.

Leaning on promises does cut out a lot of the user space complication though.

I agree this could work if framed as a coworker rubber ducking his problems to you and asking for ideas to get to a solution, because it could clear up the naming issues and focus on the candidate solving problem skills without the pressure about giving the one right answer to the problem.