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.
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.
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.
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.
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.
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?
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.)
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.
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.
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.
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.
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?
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.
Not really. These other industries are evaluating people somehow. Whether it's vibes, connections, resume, or some sort of technical evaluation you'll have a grown adult evaluating you. Hiring will always feel a bit lame and arbitrary, you have limited time and information to pick someone. You're not going to be able to understand candidates fully and you'll probably pick wrong a fair bit. So we come up with criteria that's a bit arbitrary but you need at least some effort and smarts to meet them so it's at least a bit correlated with a good hire. I don't think the non technical methods are any more or less dignified.
SW engineering is rather young, compared to others, like construction, medicine, law, etc. It doesn’t have good established patterns, which is followed by everyone.
I think the "sendOnce" question is fine. Software development is just different than other professions, and you get a lot of candidates who talk a good show but can't actually program at all. For a decent dev, this isn't programming, it's typing.
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.
Isn't it because there is a difference in your field and other fields?
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?
I had a favourite interview question when I was 3 years in. My boss tempered my enthusiasm by letting me ask it but made it not a requirement to be hired so more of a bonus "extension question". Glad they did that. I was being rediculous. I assumed "anyone who used this framework must have come across this problem" but was just an assumption.
Well, that's because in law, you can't attend a 4 week bootcamp, call yourself a lawyer and inflate the ranks of desperate looking for a job. Now, also remote.
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.
there are formal regulatory boards for most of this. Lawyers gotta pass the bar, medical folks have their own board exams, finance has things like CPA or CFP certifications, etc.
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.
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.
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.
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!
In another thread I asked if leetcode style questions are still common, and the answer I got was yes, so where would I encounter this kind of question? I only ever got leetcode style questions or something like "what is the difference between var and let"
If I were asked this question, the first thing I said would be this is a poorly designed architecture. Client is the poor place to do throttling by itself. It has no information on the aggregated load of the system. It makes assumption that leads to complicate code in the sample code. There're more robust and better ways to do flow control and throttling.
The minDelay extension feels contrived and also the solution sucks. None of the pending requests are actually added to the queue until the timeout is finished, meaning you have no knowledge of all these delayed requests until the timeout passes and they all enqueue themselves
86 comments
[ 5.4 ms ] story [ 104 ms ] threadI 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.
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?
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.)
It must be so boring working you
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?
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.
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.
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?
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.
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.
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.
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.
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.
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!
yuck