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.
Then what happens is these Leetcode heroes, never having built anything from scratch in their lives, create a hazing ritual for new candidates.
What is the point of, say, a system design interview asking to design a planet-scale system when most people never came close to one or, again, never built one because they are just out of school?
And, yes, I know - "how would you interview a recent student?".
Fine, I was a student in 2004, so why are we having the same goddamned test?
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.
We have it cushy. Really cushy. Unless you are working for a 2025 AI startup that works and pays you like a mule and uses the word mission unironically.
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.
At one company I lobbied hard against standardizing our interview on a question designed to test the candidate's multi-threaded knowledge. I insisted that if we needed multithreading, we could just ask the candidate, and ask them to elaborate. Fortunately I won that little battle.
Sometimes in interviews you get tunnel vision and you can't see the forest through the trees, and you don't realize that the interviewer is asking you about multithreading because they're being coy. That's the kind of shitty interview we need to avoid, because it leads to the false conclusion that the candidate doesn't know about multithreading when actually you just don't know how to ask.
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.
They're things you actually do, and I imagine most people applying to these roles have done, either in exercise (say in college) or in previous jobs. Its still a practical assessment.
Where software interviewing is different is the assessments aren't grounded in being all that practical
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?
Really? Do you invert linked lists all day? When the last time you had to traverse a binary tree? Genuine questions. I'm sure there has to be a mismatch between what we define as "those questions".
> They're also fairly discussion based
They're also performed wildly differently with no standards at all. I've had good coding interviews with the coding as a starting point for a conversation. But I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. The latter is particularly great at hiring professional interviewers rather than actual professionals at the job.
Now it feels like I'm back in high school, including strict irrelevant rules to be followed, people constantly checking in on you, and especially all of the petty drama and popularity contests.
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.
* Give us a presentation about a meaningful amount of work you did at a company (no NDA violations of course) and spend at least an hour talking about what you did, how you did it, what went well and what did not, and then be prepared for questions.
* Actual software development issues that the team sees every day (not hard mode, just normal) submitted as a PR - review it thoroughly.
* Given a running code environment, fix a bug (you have a debugger, full ide, and an hour to look at it) - not so much about the end result as seeing how you work and your process.
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.
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.
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.)
What if the company GitLab/DockerHub instance is restricted and you can't get code samples (I think this is very common)? Or a different example: I have a few public repositories on GitHub but most of them are private - it seems like that's something you'd perceive negatively?
For many years I played Peg Solitaire, and after reading Norvig's AI:AMA, realized that Peg Solitaire was a fairly easy game to write a solver for. It wasn't that hard to write, but it turns out that I've only ever implemented recursion using function calls to implement a stack, rather than the iterative equivalent (using a python list as a stack, and a Set to save previously visited boards). Having the confidence of the working recursive version, and then reading up on iterative implementations, i was finally able to get a working iterative version (for some reason it's really unnatural-feeling to me) working.
I like to hear candidates explain how they understood and met the customer's requirements. The code is only part of the success.
My goal for interviewing is to either hire the person, or not hire the person but have them walk away feeling like they got something out of our time together. Often I can quickly tell that the person isn't right for the role, in which case I will politely explain that to them and offer whatever advice I can.
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.
We’d get on calls with them and they’d be like “you can’t do multithreading!” we eventually parsed out that what they literally meant was that we could only make a single request to their API at a time. We’d had to integrate with them, and they weren’t going to fix it on their side.
(Our solve ended being a lot more complicated than this, as we had multiple processes across multiple machines that were potentially making concurrent requests.)
When the client(s) can send more work than the server can handle there are three options:
1 - Do nothing; server drops requests.
2 - Server notifies the clients (429 in HTTP) and client backs-off (exponential, jitter).
3 - Put the client requests in a queue.
It’s not the ability to communicate effectively that’s at play here, it’s your ability to read your interviewer’s thoughts. Sure thing, if you work with stakeholders, you need some of that as well, but you typically can iterate with them as needed, whereas you have a single shot in the interview.
Plenty of times, at the end of the interview, I do have a better mental picture of the problem and can come up with a way better solution, but “hey, 1h has already passed so get the fuck out of here. Next!”
As it stands, we still don't know why the server was broken in this way and why they created a work around in the client instead of fixing the server.
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 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.
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?
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);
https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
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.
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...
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.
> 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.
I am not against testing deeper language understanding for a job that requires it but the layers of contrivances to make it "not only js" rightfully rubs non-js devs the wrong way. This comes from someone who loves them some js.
The AI ick at the end makes what would have been mildly interesting, incoherent and uninteresting.
const PromiseQueue = {
queue: Promise.resolve(true),
sendOnce(request) {
return new Promise((resolve, reject) => {
this.queue = this.queue
.then(request)
.then(resolve)
.catch(reject)
})
}
}Are you sure? I'm not a javascript programmer and it took less than 2 minutes to comprehend. If you think this takes considerable effort to comprehend then I don't think you actually tried.
While this works, it's not exactly intuitive.
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!
(Really, it shouldn't be surprising that most technical interviewers aren't that competent, since they usually aren't selected for it.)
Corporate life meets the squid games (I quite like it:)
declare function send<P>(
payload: P,
callback: () => void
): void;
Also the signatures are Typescript, which really isn't that far off in the context of an interview. Even in a pure JS codebase it's not uncommon for IDEs to pull the TS definitions of packages to provide basic type checking. But even pure JS libraries will normally provide typed signatures in their documentation.
If anything I'd say this shows that the interviewer is prepared, by ensuring the candidate has what they need to complete the question.
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(...)
}
It must be so boring working you
yuck
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.)
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?
If there is some kind of cooperative multitasking going on, then it should be noted in the pseudo code with eg. async/await or equivalent keywords. As the code is, send() never gives back control to the calling code, until it completely finishes.
let send = (payload, callback) => fetch(...).then(callback)
fetch() returns a promise synchronously, but it's not awaited.
[1] i.e. backpressure, which would actually be the ideal way for the server to implement whatever rate limiting it wants, but we are assuming here that the server has a less than ideal interface.
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.
its certainly serialized, but nothing fancy otherwise.
it would be synchronous if you blocked the requester until the request go through the queue and then completed. you wouldnt need to introduce an async/await.
you can see examples in JS on the node FS functions. the defualt ones are async, but they have some magic wrappers that make it actually sychronous and block the event loop from running until the file is loaded
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 is also how a candidate can get to know the interviewer and possibly the company he is interviewing at. What does the interviewer say when you start picking apart what they are actually asking about.
The way this problem is posed has two main issues. The first is that it is unclear what the interviewer actually wants. The second is that the problem to be solved isn't well defined. This is later confirmed when we read the blog posting and it is revealed that rather than designing a solution to a problem, the interviewer expects the candidate to hack their way to a solution. Not to recognize what you are trying to accomplish and reason about how to solve such problems, but just peck at the problem. Mess with the code.
To make matters worse, it would appear that the interviewer is approaching the problem in a dubious manner -- solving a server problem by depending on the clients to cooperate. That should make you suspicious.
It gets further confused by adding poorly motivated extensions to the problem while misusing nomenclature. It appears he is asking for how to solve a difficult problem in messaging systems, but he isn't. He is asking for convenient ways to implement something much simpler. Which even makes me question if he would have recognized someone smarter than him misunderstanding and solving a harder problem -- someone who is capable of solving the kind of problems his use of nomenclature hints at, but apparently wasn't after.
Now, think about your reaction to this problem formulation from my perspective. From the perspective of someone who wants to hire senior developers. When I hire people I need people who can solve problems. Lacking that, I need someone I can train to solve problems. I have no need for people who dig themselves out of holes brute force. This is why some portion of my interview questions will only work if the candidate asks questions. Some of these interview questions are really easy to solve from a technical/algorithmic point of view, but only if you can identify the underlying problem.
If I had presented the problem as stated to a candidate and they did what the interviewer seemed to want, I'd probably have added them to the reject pile for lack of ability to take a step back and point out that this is a bit silly.
The interviewer would fail you because this interviewer wants to feel superior and more powerful. Your attempt to help them do better would enrage their sense that this interview must be putting them above you.
Their conclusion would be you are arrogant and hard to work with and you did not understand the simple problem that they explained and they would fail you.
All if that is clearly explained in the blog post, indirectly.
Not necessarily. The interviewer may only be insecure, inexperienced or not terribly good at conducting interviews. Of course, to the candidate this doesn't make much of a difference.
I'm not so sure this interviewer actually feels superior. I think he feels insecure. And with good reason.
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 other examples given for fleshing it out are all pretty similar; if a candidate can do one, chances are they can do the others too. If you want to get a decent signal if candidate skill, you have to ask a question easy enough that any candidate you'd accept can answer it, then incrementally add difficulty until you've given the candidate a chance to show off the limit of their abilities (at least as applied to your question).
Otherwise you ask a too-easy question which everyone nails, then make it way too hard and everyone fails. Or you ask a too-easy question and follow it up with additional enhancements that don't actually add much difficulty, and again all the candidates look similar. That's just my experience; the author seems pleased with the question so maybe they're getting good signal out of it.
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.
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.
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.
This seems to be an interview question about JS esoterica, not concurrent programming.
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).
None of these interview questions are hard. They are just either domain specific (like callbacks/promises/async/await) or designed to trip you up on details.
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)
its still not a great architecture, but its different from throttling
“… it doesn't ever have to handle more than one request at once (at least from the same client, so we can assume this is a single-server per-client type of architecture).“
For sure a multithreaded async queue would be a very interesting interview, but if you started with the send system the interview is constructed around youd run out of time quickly.
const lockify = f => {
let lock = Promise.resolve()
return (...args) => {
const result = lock.then(() => f(...args))
lock = result.catch(() => {})
return result.then(v => v)
}
}It makes no sense even with common js idiom.
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
How does this change the point? They would still like the best candidate out of that pool, not any warm body, since they have limited positions.
What is your approach to hiring and evaluating talent knowing the large number of applicants and how easy it is to _talk about software development_ vs. _actually developing software_, and how expensive and difficult it is to deal with a bad hire, even in America.
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")
> 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.
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.
In this sense what use is the “proper” implementation in the blog?
In general interview programming questions really feel useless, especially if you consider candidates will be optimising for solving interview questions instead of being good at doing their job
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.
export interface AsyncQueueOptions {
timeoutSeconds?: number
}
export class AsyncQueue<T> {
private readonly queue: Promise<T | undefined>[] = []
readonly timeoutSeconds: number
private timeout: ReturnType<typeof setTimeout> | undefined
private reject = () => {}
private resolve = (value: T | PromiseLike<T>) => {}
/**
* @param timeoutSeconds @default 25
*/
constructor({ timeoutSeconds = 25 }: AsyncQueueOptions = {}) {
this.timeoutSeconds = timeoutSeconds
if (timeoutSeconds > 100) {
console.warn(`You are initializing AsyncQueue with over 100s timeout: ${timeoutSeconds}`)
}
this.queue.push(
new Promise<T | undefined>((resolve, reject) => {
this.resolve = resolve
this.reject = reject
this.timeout = setTimeout(() => resolve(undefined), timeoutSeconds * 1000)
})
)
}
next(): Promise<T | undefined> | undefined {
return this.queue.shift()
}
push(msg: T) {
this.resolve(msg)
this.queue.push(
new Promise<T | undefined>((resolve, reject) => {
this.resolve = resolve
this.reject = reject
clearTimeout(this.timeout)
this.timeout = setTimeout(() => resolve(undefined), this.timeoutSeconds * 1000)
})
)
}
close(msg?: T) {
if (msg) {
this.resolve(msg)
}
clearTimeout(this.timeout)
}
}Just say no thanks and walk out if this is their core way to assess your capabilities.
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.
> So, we decide to make our server's life easier by trying to ensure, from the client, that it doesn't ever have to handle more than one request at once (at least from the same client, so we can assume this is a single-server per-client type of architecture).
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.
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.
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.
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.