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.
It's because our profession seems to attract a number of intellectually insecure people who thrive on these little puzzles and the associated minutiae as a means of feeling a sense of superiority. They all think they've figured it out: the best way to tell if someone is a Good Dev or a Shit Dev. Of course, administering the test, there's no way they could possibly be anything but the Good Dev. It is embarrassing. Don't believe me? Why can't they help but blog about it?
We have FAANG to thank for this. They pioneer counterproductive interview questions (remember puzzles?), and the industry just copies these trends, like zombies.
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?
Not entirely, though FAANG companies certainly didn't do anything to help make it better.
I'm 51 and have been a professional software developer since the early to mid 1990s and tech interviewing was already a strange hazing ritual disaster before FAANG existed.
I distinctly remember interviewing for a QA position in the 90's where I was asked how I would test a soda vending machine. I was dinged because I didn't mention that I would make sure the sodas were cold.
The real problem: How you accurately evaluate a candidate without these questions? I dislike them as much as the next person, but I don't know a better way. Literally, all the best tech firms and ibanks do it. They pay the most and are most profitable. They must be doing something right. The real trick is finding a "fractically complex" question with many levels. The one in this blog is pretty good! No candidate can solve it perfectly in the allotted time, but you can have a good discussion about the "edges" of the problem -- where good candidates shine.
How do you accurately evaluate candidates with them?
It's an artificial test that doesn't reflect your working environment at all, and so you're not actually getting to see what they'd be capable of doing faced with real world coding work.
It's a discriminatory practice that is proven bad for a lot of neurodivergent candidates, like folks with autism, or ADHD.
You end up eliminating a whole lot of good candidates just by the structure, and then end up picking up a candidate who happens to do well out of that small subset and it still won't stop you from hiring developers that are terrible.
One of the worst developers I've ever worked with will absolutely sail through leetcode exercises. He's brilliant at it. Something about his brain excels in that environment. If only work was like a leetcode interview, filled with leetcode style questions, and someone watching and evaluating his work as he did it, he'd be a fine hire anywhere.
He can't write actual production software to save his arse, needs deadline pressure breathing down his neck, and then what he'll produce at the last minute (always technically makes the deadline), will probably work but is the most unmaintainable nightmare that needs to be rejected and redone by another developer.
I have had the exact same experience with the exact same kind of person. We used to be in the same team for years and after we collaborated once, I absolutely hated any work interaction related to his him or his work. Outside of work we got along well, he was fine, socially stunted, but that's OK.
When the layoff time came, everyone had to scramble to move by themselves to a small selection of teams. The second I heard that guy was interviewing for the same team as me, I had gotten an offer at that point, I told the hiring manager, me or him. That's how bad working with those kinds of people can be. He ended up elsewhere and I'm still in that team. I just could not deal with him anymore. Perfect interviewer, but couldn't write production code to save his life... He's still employed by the way, bumbling around from team to team because the consequences of his incompetence take months or years to feel...
What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices. Likely other hiring practices would have worked fine as well.
>> Literally, all the best tech firms and ibanks do it. They must be doing something right.
Reasoning by first principles isn't exactly the software industry's strong point.
> What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices.
Agreed though I'm not sure I'd be as generous as you are when it comes to their business models being that great in absolute terms.
Strip away all the confirmation and survivorship bias and IMO it is pretty obvious a lot of the success of tech in general for multiple decades running was almost entirely the result of the free money lottery system funded by zero interest rates.
I really counsel everyone to stop thinking like this. The appealing to authority doesn't work when you are talking about different sized businesses.
All the best banks and tech firms do a lot of things that could be categorized as wasteful, useless, inertia maintaining, etc, adopting their practices without a thorough understanding if it applies to your business is plainly just stupid.
Your business is not structured like those big business, you are not as anemic to risk as they are (otherwise you wouldn't even create your business in the first place), you don't have their cash, you don't have their ability to spend an enormous amount of time hiring every single person because your profits cushion you from all your dumb decisions.
This is my own experience but I find the evaluation on interest and intellectual curiosity to be more validating long term than being able to rote memorize problems.
Edit: To add some color, I want a candidate who is excited to program, I don’t care as much about their ability beyond having the basics which I find pretty easy to figure out in an initial conversation. Candidates who are excited for the opportunity are generally the ones who I find to excel in the long run.
If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.
I trust they were really competent, but it's a bit depressing that these competent people will need to go through the leetcode rituals and 5-10 interviews to get a new job at Meta, Netflix, AWS or adjacent companies. That's actually the point of the original post; you are never judged by your (years of) experience or even your past companies, only by the results of a test from a random person/company.
I disagree; I don't think a full day of interviews is a huge price to pay for a FAANG job. The stakes are high for the employer, the rewards are high for successful applicants, and if you get to that stage, you've already passed a lower-stakes phone screen.
Put yourself in the employer's shoes: You want a high-quality SWE, you're prepared to pay them top dollar, but if they turn out to be not so great, it's expensive to get rid of them. Would you be satisfied by years of experience at other companies by itself, when you know that (like in many job markets) there's a big market for lemons? I wouldn't. I would want to see the candidate demonstrate some specific skills -- ideally the skills they'd be using day-to-day, but if that's not feasible for time reasons (it usually isn't), then adjacent skills that generally imply (though are not necessarily implied by) them, like recognising the shape of a toy problem, and knowing and applying the right algorithm to solve it.
I am not commenting on the interview effort-salary ratio, but the fact that credentials and experience mean nothing to the tech industry, also comparing to the rest of professions. I mean working in Google/Meta/Netflix, is like working on the best hospital if you are a doctor, in the best construction industry if you are an engineer, to best law firm if you are a lawyer, etc. Imagine having to pass a leetcode or iq test everytime you want to move to the next one. I definitely know that my cousin, who is an exceptional doctor in Greece with only 10 years of experience, laughs about it.
This is not true. It is basically impossible to hit L7 before 30 years old. A lot of it is indirectly related to experience: What have you accomplished for us. MDs on Wall Street trading floors are similar. It is very hard (nearly impossible) to make MD before 30 in this era.
I think it should be the other way round: In an ideal world, everyone, including doctors and executives, should expect to have to demonstrate their skills when applying for a new job.
It's just unfortunate that there isn't (TTBOMK) an easy way of measuring, in a few hours, how good an executive is at executive-ing. Which is why the field is crammed with useless pretenders who nevertheless manage to flit from job to job, soaking up fat compensation packages before their incompetence is exposed.
I'm curious why there doesn't seem to be the same market for lemons for doctors. Or is there? How does a person actually know if a doctor is good?
> executives, should expect to have to demonstrate their skills when applying for a new job
They do. The interview process is a review of your "wins and losses" (public and verifiable is the gold standard), plus you need to complete some case studies.
I am glad that you mentioned Google. At this point, their interview process is legendary. It is so good that many other companies have tried to copy it.
For me too, anyone that does horribly, bad signal. Anyone who does perfectly, bad signal.
I've found that looking for mediocre and sub-par results will give you professionals that spend their time getting good at the profession instead of getting good at leetcoding.
I have never and will never hire code monkeys. AI already takes care of that.
1. Because it is so dynamic and subjective, it is very hard to systematize this kind of interview, which makes it very hard to work into a repeatable or scalable process. The need to compare incoming candidates is an unfortunate reality of the industry for many companies.
1b. It is basically impossible to control for bias and things like "was the interviewer having a good day".
2. This kind of interview overly rewards charismatic speakers -- this is partially ok, depending on the role, because being able to speak accurately and cogently about the work you're doing and are going to do is part of the job (especially for staff+ engineering). It isn't necessary for all jobs, however.
3. Many people aren't good at driving this kind of conversation for whatever reason. When it goes well it goes well but when this kind of conversation goes poorly it reflects badly on the company.
4. People Ops want more control then this gives them, across many dimensions.
I had in mind the problem given in TFA, but I should have been explicit about that.
I think it's probably too hard as an interview question, but also that it actually is a somewhat realistic problem that I'd expect a senior programmer to (eventually) puzzle out correctly. (As opposed to, say, the archetypal bad interview question, "How do you swap two integer values without using a temporary?", where many people happen to already know the trick, and if you don't, you're unlikely to figure it out on your own in the space of an interview.)
Hiring that guy is a badge of honor because admitting otherwise would be to admit that the interview processes have nothing to do with the job, thus the real incompetence here is with the companies and people following that interviewing style.
Instead of correcting themselves, those interviewers chose to dive deeper into delusion.
Accurately evaluating a candidate is impossible, but surely asking a candidate these questions will yoeld a lower quality worker than if you ask them something related to the work they might do.
I disagree. I always go back to the blog posts that Joel Spolsky wrote 20+ years ago about his theory of hiring. The primary goal is to avoid bad hires. Even simple tech problems can easily eliminate (or rank) many software devs. As someone who regularly interviews candidates, I am blown away how bad are many of them.
I think a lot of fields of engineering have analogous questions actually. EEs ask to explain a circuit or draw a new one. Mech Es ask to design some piece of simple hardware with a clever catch. Interviewing is just hard, it’s impossible to cover breadth of knowledge in 45 mins so we end up with little brain teasers.
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.
Lawyers have law school after a degree, a bar exam, legal liability for malpractice, and ongoing licensing requirements.
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.
The difference is that if you fail medicine, it’s ok (it’s hard). But if you fail to get a job because of the stupid “async queue” author’s problem, well, that’s depressing.
I'm not so sure. Failing your residency means your medical career is basically done, and you have to basically start a new career from scratch in your late 20s. Chances are you'll have debt from not just undergrad but also med school.
By comparison, failing a leetcode interview means you've got to find a new company to interview with.
failing medicine is depressing in the original sense of giving personal depression, failing stupid leetcode and not getting job is depressing in the more modern sense of the world is stupid and not well-organized.
I know its not a popular opinion here or elsewhere, but since these interviews are so standard, why don't we have a uniform standard body where I can get a licensure, do yearly trainings etc as a software engineer? It would solve the same problem something like the CPA exam does.
Nope. In my opinion Wild West in software is much preferred model. If one wants to create software and sell it there should be no barriers. It is one of the the very few fields that give chance to simple people with no money to break out and live decent life.
Tbh I think it depends on the domain you are coding for. The field is so diverse across many different parts of the economy. E-Commerce web app sure go for your life -> software for controlling some life support system... yeah maybe I want someone with qualifications and audited standards thanks.
Life support and controls system should absolutely have a high standard, but even E-Commerce should have a decent bar. If you're handling my money I expect you to be an adult.
Sure. But audits/processes only catch up to a point. In the end the buck stops with a professional. That's what most "professions" are. They aren't just a service -> they are an accreditation with some recourse which gives them prestige/social status/etc if they have years of experience (i.e. despite the risk imposed on them as a professional they have survived/thrived).
Its not common that people in our industry don't have bachelor degrees anymore. Its also not an industry where I routinely find the majority of people come from lower economic backgrounds etc.
I think a fair compromise would be not to require specific degrees to test, but rather a service fee (which could be sponsored) but I think a similar rigorous standards based exam would do wonders for our industry, even if it trims who can enter it on the margins
>"Its not common that people in our industry don't have bachelor degrees anymore. Its also not an industry where I routinely find the majority of people come from lower economic backgrounds etc."
It does not matter what you "routinely find". Live and let live. Person has an inherent right to make living however they see fit unless it actively harms others.
If you are so concerned about degrees why not to start with the one of a "decent human" and require it from politicians. Those fuckers affect us way more than any software and and mostly walk free no matter haw badly they fuck someone's life
Your attitude is completely off-base. Would you get treated by a doctor who was not recognized by the AMA? Would you hire a lawyer who was not called to the bar, or an accountant who was not chartered or equivalent?
Yet somehow a high school education is sufficient to write software for a 4000 lbs vehicle moving at 60 mph.
>"Yet somehow a high school education is sufficient to write software for a 4000 lbs vehicle moving at 60 mph."
Cut the BS please. Safety critical software gets audited and other measures are taken to insure it stays safe to a degree. However if one wants to write software for let's say music synthesizer the only thing that matter is the person ability. In this case I would look for experience, list of completed projects and other relevant info. I would not give a rat's ass about their diploma. Some of the best / successful software was often created by domain experts who learned how to program.
because our industry would improve massively if we actually removed a barrier to allowing standardized licensure
I also never said it should be held behind a degree, instead I said a fee, which could be sponsored. No degree required, though one certainly would help I imagine.
We live in a society, and we should think beyond the individual in terms of benefits. This would be a big win for society.
those generic screener questions aren't technology specific. Data structures, algorithms, system design (the top 3 that show up in interviews), none of which are technology specific.
Throw in best practices like TDD, code security, and architectural patterns and I think you could hit all of the most common non technology specific domains that cover it
Many people in software have passed through similarly hard gates in the past.
An engineering degree is harder to attain than a law degree for instance. The question isn't about these gates, it is about the interview practice once one is already through. Do law or medical interviews include questions unrelated to the work that they do in a reasonably analogous manner to leetcode? Maybe they do. Perhaps hiring is broken in all fields.
> Many people in software have passed through similarly hard gates in the past.
I didn't. I dropped out of school to work at my first job. That's different from a doctor, nurse, lawyer, CPA or PE who have to meet an industry standard.
to put it another way there isn’t this much focus on show me you know this weird problem that I’ve been studying for 5 years as well me, your 5 min timer starts now
Oh yeah. Spoke quite a bit to a doctor who wanted to get into a speciality last year. That shits hard. Intersection of mentally hard, hours demanding and high bars to entry.
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.
> does anyone else get embarrassed of their career choice when you read things like this?
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.
I used to give a code review task, of some particularly egregious python code. I'd provide all help with the syntax, and emphasise strongly upfront I don't expect them to know python or its syntax. It has proven to be a low stress task for candidates. They're not trying to solve a brain teaser, they're just doing something that's going to be part of the job. Reading code, understanding what it is doing, and providing feedback to make it more maintainable.
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.
The most "refreshing" interview I had was one where the guy had a list of like 100 questions about C++, and he would just go through and ask "do you know what SIMD is?" or "are you familiar with smart pointers?" or "tell me about templates" (most were less open ended than the template one). If I responded yes, he'd follow up, and it was more of a discussion. If I said no he'd just move on to the next one (sometimes I'd ask what it was and he'd explain).
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 build teams in their own broken image of what a good programmer should be, and then get to manager and director and mould entire companies the same way.
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.
The higher layer of people in our industry aren’t subjected to those questions. They are evaluated and get jobs more like in law and medicine, ie based on connections and track of record.
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.
Of course it's not right. Let's be honest, our profession is in the era where software engineer = factory worker, and the worst part is that we have been playing music chairs right for the last couple years. So yeah all these professions have some steady status/wealth/qol progression and upgrade while people gain years of experience, while in software development it doesn't matter how many years of experience we have, which companies we worked on, their sector, whether your company is using the saas we were working on, etc.; we are going to get judged by trivia questions and leetcode.
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.
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.
I had lunch with a friend who was trying to get a job at a law firm and they told me that their interview was just vibes and if they asked him actual law questions it would be refreshing. So maybe things aren't necessarily greener on the other side?
Other fields definitely involve similar lines of questioning in interviews. Medicine and law are special cases because they have their own set of standards that must be passed before you can even get an interview, but private equity interviews definitely include case studies/technical questions in a similar vein to the one shared in this post.
I heard that private equity does the equivalent. They show you balance sheet of a potential takeover candidate then ask for feedback. I assume that good candidates will need to do some Excel to answer their questions. Also, interviewing for trader roles at ibanks is similar. Show a trading scenario, ask what they would do and why. I guess law must be similar as well.
The difference to me is this: they're real analyst questions that you will have likely dealt with before in some detail, and not an obscure algorithm I maybe haven't seen since college or a leetcode not particularly real world presented or relevant brain teaser.
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
> But does anyone else get embarrassed of their career choice when you read things like this?
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?
> 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.
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.
> I'm sure there has to be a mismatch between what we define as "those questions".
When I said "these questions" in my comment, I meant the questions in the article. That's what this discussion is about! Those are not inverting linked lists or traversing binary trees. They're about networking, asynchronous actions and time outs.
And yes, I do deal with those things all them. Maybe not every day, but certainly multiple times in each project. Ever had to deal with a timer where it might still be triggered even after you've cancelled it [1] (because its underlying implementation has already fired but the callback is still waiting in the completion queue)? Or even trigger twice because you then re-set it while the first callback was still in the queue? That's just an example, but that's exactly the sort of fiddly condition that permeates every corner of a heavily async or multithreaded / distributed system. If your work involves that then it's totally fair to ask about them in interviews.
> ... I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. ...
Well, I agree, that's bad. But, as you say, the same questions can go either way depending on the interviewer. The very reason that I mentioned these being "discussion based" in my comment was because I took it as read that silly tricky questions are bad and to make the point that these questions don't seem to be designed for that.
Are we not allowed to ask technical questions in an interview just because some interviewers are bad? Should we be "embarrassed" about the questions in the article, as was said in the comment that I was replying to? That was what I was objecting to.
When I started writing code for a living 30 years ago, we were mostly left alone to solve problems.
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.
Don't know how many experience you get but other fields have a lot of these. Accountance have certificates, finance / quant have to solve headmaths type of problems.
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.
Long ago, I worked for a contractor company, so my colleagues and I had a lot of interviews to get sub-hired. As we had many of those interviews, we got pretty good at them, and we shared our experiences, knew popular tricky questions (like "swap using [place here any constraint]") and had names for different types of interviews. "Kick in the balls" was one of them, tricky questions which showed nothing, except that somebody solved that particular narrow problem or was already familiar with that question.
Having that experience, I know that the only reasonable interview is an open conversation. What was your last project? What was the architecture? What was problematic? How did you solve that? How did you come up with the solution? And so on. The candidate is relaxed, drinks coffee, and talks. After 1 hour, you know who you're dealing with.
If there's time, a pair coding session is informative. There are many small hints, like using shortcuts, that give away pros.
I have tried the first two things in that list. I haven't tried the third. I would need to think about how to do that in a way that is general enough that it can be re-used across candidates with different skill sets. I like the idea, though. Thanks for sharing it.
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.
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?
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.
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.
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.
When I interview a candidate, I focus primarily on what they've done. Ideally they'd have a body of work online that I can view beforehand. Then I go through a high level system design and have a collaborative conversation. Last, I give a pretty straightforward coding question, whose purpose is only to make sure they aren't full of shit, which often they are.
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.
I follow the dame process. I explain beforehand what kind of questions will be asked, and emphasize there are no tricky questions, that we are just curious about their experience, area of interest, preferences for designing ode, how they tackle ode quality and user support, etc.
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.)
> didn't have anything public on github/company gitlab/dockerhub/researchgate/
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?
As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain that without too much trouble.
Asking them about decisions in the project, issues, pros and cons of tools, etc., normally clarifies whether they understand things or not.
And as I replied in the other comment too, unfortunately if there is another candidate with very similar profile & good answers, then I'll give my technical assessment to the manager of the position, and it'll be up to the manager and humans resources to choose based on risk to the company, what they can see from public papers/conferences/repositories/etc.
In some cases, even if the work is not public, they can tell us what projects they worked. I work with climate models, so if they mention they don't have anything public, but they were using IFS, FESOM, ICON, SCHISM, or another model that I know/work with, then I'd direct questions on that model, to check what part of the model they worked on or used, who they worked with, etc.
For me not having something public is not a blocker for hiring. Just something that simplifies the hiring process -- although, lately I've had a lot of candidates with many personal projects, no branches, no pull requests, not showing experience with Git, etc. (i.e. in some cases it seems some people try to create many repositories just to show that they have something... which can be a red flag too).
Great question. I'm okay with someone who doesn't have public code, although they will have to work a little harder to verify their skills match their story.
You have some public repos. That's plenty. Even some gists will work
I tell people all the time, if you want to make it easier to get hired, put some work online. This is especially helpful for those without great credentials or history. Take advantage of this, as it's not possible in many other professions.
Agreed. Another thing that helps is writing. If you have a blog, it helps tremendously as it's possible to learn a lot from an engineer when the posts contain some thoughts about what that person learned or worked on, some opinions, techniques and tools used, etc.
Even these Linkedin posts are fine, as long as it's not an ad to some tool, or just full of buzzwords.
The kind of "behind the trenches" posts are great too, to explain something that happened in a project, a challenge you had, how you debugged a problem. This saves a lot of time in the interview as I would read it all and use that to discuss with the candidate.
What I've done is create one github project in my repo that is public, well-architected, implemented, tested, and commented. That's what I share if somebody wants a code example. I wrote the whole thing from scratch based on personal knowledge and some documentation (pyparsing and SMILES strings). I wrote it while working for a company, and went through their open-sourcing of personal work process.
I guess they just don't want to hire/interview workers who don't have public work. Maybe they pay very well and can be selective with their candidates, especially in this market. Or they live in some SV bubble where every workers has public work so it's the norm where they live.
Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
No bubble here, I think. I'm also based in EU, Spain, where job market is super competitive right now, and it's quite hard to find candidates.
As I said, it doesn't need to be only public repositories. If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries. If the answer is no (happened just a few days ago), then I ask what they used. I expect them to say something like Artifactory, Nexus, a directory on a server or HPC, or just explain why they didn't need a registry. For me there is really no wrong answer here. But if they reply they don't have anything public, and have no idea what's a container registry, then that's probably bad -- this is what I think OP of this thread meant by eliminating candidates that are full of---.
> Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
My wife also works here, and she's a recruiter in a EU company, in cancer/research. Most applicants won't have things public in that case, but they can still explain things. If there is a candidate with similar profile, that managers liked, and they have a lot of good work, public, then it's up to managers. I just explain what I saw in the repositories, whether I'd work with the candidates, and the managers hiring choose based on risk for companies.
As you are based in EU, you probably have the same problem that the hiring process can be expensive for company, and risky if you eliminate candidates, and have to go back during the experience/trial period of candidates.
> job market is super competitive right now, and it's quite hard to find candidates
Sounds like a contradiction. If it's super competitive shouldn't it be easy to find candidates?
> If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries.
How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?
Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.
So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises
> Sounds like a contradiction. If it's super competitive shouldn't it be easy to find candidates?
I know, it should be the other way around. I asked some locals, and so far some of the best answers I got for this are that the best brains here are abroad, at the Netherlands, Germany, etc.. There's a lot of applicants for every position we advertise (especially if we need someone from DevOps or Web -- not so much for Fortran, Scientific Programming, but that's normal).
But most don't pass the first filter. We try to select those that fill the basic criteria, even if they don't fill all the boxes (it's alright to learn on the job for us), even select some that do not pass to call for a short interview with HR or even with manager, but it's quite hard to find good candidates.
> How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?
It's quite common for some companies in my current field, earth sciences. Many companies have public GitLab servers, or host their own containers (e.g. Mercator Ocean International, DKRZ, ECMWF, etc.).
As I mentioned in other comments, I'd interview someone that doesn't have public repositories or containers anyway. But in the end, if there are other candidates with good CVs, and interesting projects public on GitHub, etc., or if they collaborated to good Open Source projects (Dask, Xarray, Singularity, Jenkins, Python, fortran, etc.) changes increase.
> Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.
I worked in banks, insurance, credit bureau, telco, and government. In most of these the work was done in private CVS, Subversion, or Git servers.
But in most of these, we used Open Source projects, and normally we were allowed to send contributions back upstream, when we found bugs in numpy, python, etc.. There were some companies where I couldn't contribute, so I can only explain the systems I worked, and the tech stack we had.
> So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises
We hire people without public repositories too. Having worked at FOSS projects/enterprises definitely helps.
It's the same as the degree you have. In the end it may be an advantage depending on the company. I, particularly, do not care much if someone is coming from physics, mathematics, economics, biology, or even architecture (we just hired an architect that enrolled in a CS degree in Portugal to work with data pipelines/NetCDF/xarray/etc.).
As long as the person has the technical knowledge required for the job, and some experience if needed, that's fine by me. But I worked with manager that only hired those coming from CS.
So even those with good public contributions or coming from enterprise/FOSS, acing a technical test, etc., nothing would help you to be selected when applying for that team.
In our case we had a junior position in the data team, and advertised it in Linkedin and asked others to spread word to friends/bluesky/etc.
Somehow, that person heard about the position, and was already trying to transition from architecture to IT (had enrolled in an open university course of CS -- online, remote).
We really try to interview as many as we can, give a fair chance to all (ignoring background, gender, etc., focusing on what's needed for the position).
Human resources did the first triage (assessing character/personality [one of those simple psychology assessment tests], level of English, visa/work permit/etc.).
Then the managers for the position (department leader + group leader) reviewed CVs and prepared brief interviews, followed by a final technical interview. That's it.
That person did not have a lot of experience, little visible in GitHub, having only studied IT for a few months, but he was really trying hard. The managers liked his attitude, and believed he was the best fit for the position.
He's now learning Git, Docker, Python, NetCDF, etc. In fact, today we will have a quick chat near the waterfountain/coffee machine as he asked me if we could chat as he had questions about pyproject.toml and building Python packages.
I believe if instead he had showed some projects with Python and NetCDF, and said he was looking into enrolling in a CS degree or take some courses, that could have been a replacement for the CS degree.
So tell your friend to try to choose what s/he prefers (data, programming, performance, DevOps, web, algorithms, compilers, etc.), and try to either create a public portfolio, or study hard so that in an interview s/he can answer questions well, showing some knowledge & interest (e.g. in this case, knowing what's NetCDF is, what's GRIB/BUFR, xarray, etc., even without a lot of hands-on experience could have been an advantage).
> Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
This mirrors my experience as well.
I tend to do some side projects on the side but, seeing as I do them for fun, I don't take them as seriously. I'd hate to be judged based on work like this over something I'd do in a professional setting.
That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
> That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
Yeah, I'd also hate to be in that position where I may be the best candidate for a position but somebody else got it just because they have public projects. But at the end, the managers/HR/technical team/etc. are all trying to minimize risks to the company and projects.
I did this once! I was given a "create Battleship" take-home assignment. Normally, I'd say, "yeah, I don't have time for this". But I happen to really like that game and had never thought of how to model it in code. So I took up the challenge. I spent time whiteboarding classes, interfaces, writing tests... in the end, I had a solid solution. I submitted my code and as I was doing so, I thought, "you know, this really could be handled by a couple of Set data structures. After hitting send, I did a quick follow-up with, "you know, this has a very simple solution" and typed some example code right in the body of the email. I love it when I can't just leave a problem alone. The hiring manager appreciated it too!
Isn't it fun when you can take a game you play and write an implementation (both the game and the solver), thinking through all the details, and at the end, the solution is simple, elegant, and enlightening?
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.
Agree, although this is often an undeveloped skill in newer folks. There are many other things I like to discuss in an interview: past mistakes, things they are especially proud of, times they trimmed scope to meet a deadline, working with difficult people, etc.
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.
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.
I agree to a point. For me, what chaffs is the convulted prompt that goes against all my instincts for how to design something simply and clearly.
"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 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.
Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.
Exactly. If I were asked this question during an interview, the first thing I'd say is "why should the client bother with anything more complex than jittered exponential backoff?"
I've dealt with backends that refresh a CSRF token on each valid request and return it in the response as a cookie. In those cases a solution like this may be needed. Not optimal but, we don't always have control over the backends we use, especially then they're provided by a third party.
I've had to implement this exact logic at work, because we have to talk to devices using modbus tcp, where a lot of devices only supports having one active request per connection at a time. One device we talk to only supports having 5 active connections to it.
I've dealt with low-limit APIs, and I've always considered the better approach to the problem is to create a proxy rather than trust the clients to manage, limit and coordinate themselves.
Then we send all traffic to proxy.service instead of canon.service, and implement queuing, rate limiting, caching, etc on the proxy.
This shields the weak part of the system from the clients.
I guess I hadn't considered the existence of generic TCP proxies
And I'd probably have concerns around how much latency it would introduce in an environment where we have some requirements on the rate of data collection.
That said our service Does act as a kind of proxy for a few protocols.
Because you only control the client, but you need to integrate with that broken server of a third party. It’s a pretty common situation to find oneself in.
Yup. I've even found myself in situations where the owner of the third-party service is another team or department within the organization I'm working for or partnering with. Oftentimes, the product/project people on our team tries to make it a business issue with the partner only to find that they don't have the leverage to effect a fix, they get told that the service doesn't offer the SLA you require, or you hear back from the team some hilarious quote like six weeks of development that can't begin until the next quarter. Meanwhile, your feature or product has to launch by the end of the current sprint or quarter.
What happens when the unstoppable force meets the immovable object? The unstoppable force works over the weekend to implement a store-and-forward solution.
FWIW I’ve basically been given basically this exact requirement by a partner with a crappy API.
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.)
> Not actually that hard with a redis lock or any database (Postgres has a specific lock for this but you could also just use a record in a table)
Redis is just another SPOF, and so is Postgres without fiddly third party extensions (that are pretty unreliable in practice, IME). I'm talking about something truly distributed.
What, you need something truly "internet-scale" to make sure your thousands of clients can hit, sequentially, that one faulty api? Would you really be concerned more about Redis failure rates, than said API's failure rates?
If you get into that situation then it's probably because that API is critical and irreplaceable (otherwise you wouldn't be tolerating its problems), so you really don't want to get stuck and be unable to query it. And if you can tolerate a SPOF then there's no reason to bring Redis/Postgres into the picture, you might as well just have a single server doing it.
Plus it's just good practice that I'd want to be following anyway. Once you get in the habit of doing it it doesn't really cost much to design the dataflow right up-front, and it can save you from getting trapped down the line when it's much harder to fix things. Especially for an interview-type situation, why not design it right?
Does a truly distributed solution have no additional cost at all?
To be honest, for me, in an interview-type situation, if you insist that Redis is the problem in that scenario - you would have failed the interview (the interview is never one-way, interviewers can fail it too).
> Does a truly distributed solution have no additional cost at all?
If you literally just drop in etcd or Zookeeper rather than Redis and then develop in the same way then I'd say there's no additional cost to doing that. (I mean sure if you dig hard enough you can always find a way in which solution A is worse than solution B - e.g. most things have worse latency than Redis - but in this scenario the latency of the external API is going to make that irrelevant). Of course if you're just running those in single-node mode and developing against them without thinking about the distributed issues then you've still got plenty of ways to shoot yourself in the foot, but it's a small step in the right direction.
Developing more fully distributed from day 1 requires discipline that takes time to learn, but I'm not convinced that it's actually slower - I'd compare it to e.g. using a strongly typed language, where initially you spend a lot of time bouncing off the guardrails, but over time you adapt yourself and can be productive very rapidly on new projects.
> To be honest, for me, in an interview-type situation, if you insist that Redis is the problem in that scenario - you would have failed the interview (the interview is never one-way, interviewers can fail it too).
Interesting - to me Redis in a system design is very often a case of over-architecting. It's easy to use and programmers enjoy working with it, but very often it isn't letting you do anything you couldn't do without it, and while it can speed things up, I see a lot of cases where the thing it speeds up is something that was already fast enough.
TBH I didn't communicate that clearly - my point was not "Redis in particular", but "whatever you already have at hand, for this usecase". Could also be Postgres or another SQL server.
1 etcd pod doesn't give you "no SPOF", you need 3, and then you need them on multiple VMs (or physical machines if you're not on the cloud/not in k8s), and then the cluster needs to be multi-AZ, and if you're really serious about the "no spof" that may mean geo-redundancy too... come on, just the deployment costs alone are significant.
> my point was not "Redis in particular", but "whatever you already have at hand, for this usecase". Could also be Postgres or another SQL server.
But if you're in the habit of using HA-capable systems then whatever you have to hand will be HA-capable, and so there won't really be any additional cost to using that.
And again, I think there's a real antipattern where people take a single-server application and then claim they've made it fault tolerant by making it run on multiple hosts, but it's still relying on a single DB server. In my experience that doesn't actually improve reliability any (at least not if you've got a good deployment process for your single-server application) and it complicates your architecture to no real benefit. (Indeed, frankly, I think a lot of developers reach for an external database because they have no other idea how to store data from their application, when using embedded sqlite/hbase or - shudder! - the local filesystem, would let them use much simpler architecture and not really reduce the actual reliability of the system).
> 1 etcd pod doesn't give you "no SPOF"
No, but it gives you a clear path to removing your SPOF when the need arises. Which is much harder if you've built your system on Redis.
A server that has a spike of load and can't cope with it is pretty normal, hard to characterize as "broken".
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.
Interview question/solution does 2 in a poor way (just adding a pause), it's part of the client and does 3 in the client, when usually this is done in an intermediate component (RMQ/Kafka/Redis/Db/whatever).
Because it was written in ALGOL 60, none of the mainframe devs are willing to touch that code, and the dozen other clients probably depend on the broken functionality.
That makes it even better, the candidate should ask clarifying questions. I've worked with people who, when encountering some amount of ambiguity, either throw their hands up, or make some random assumptions. Ability to communicate effectively to bridge the gaps in understanding is what I'd expect from any candidate, especially more senior ones.
But that doesn’t work. One could ask why server can handle only one request? Why can’t we upgrade (vertically or horizontally) the server? Why the logic needs to live in the client? And a large etc.
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!”
> One could ask why server can handle only one request?
I've tried that approach in a couple of interviews and, no surprise, I did not get those jobs because interviewers really seem to hate it if you dare step outside the little cocoon of leet they've constructed.
Those are bad questions. The task is given, you're asking why do I have these constraints - obviously you have them because they made them. Without the constraints there's no task.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.
On the contrary, these are great questions to raise at the start and I'd absolutely rate a candidate better for asking them. Too many of my coworkers solve the wrong problem. They treat the symptoms instead of finding the root cause, and so we end up with a fragile patchwork of dirty hacks that get cargo-culted into other code bases.
That being said, the time spent on these questions should be minimal. It should go something like:
Candidate: It seems like we're solving the wrong problem. Why can't the server handle multiple simultaneous requests from a single client?
Interviewer: Its a 3rd-party server we don't control. (or even just a "because those are the artificial constraints for this puzzle" if the interviewer is feeling particularly lazy)
Candidate: Ah okay. <proceeds to work on the problem>
Sure, that's completely reasonable. But getting hung up on them for an hour is ridiculous.
I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
Sure, but this isn't a back&forth interview - it's a blog post. The author could have included a section with clarifying questions they expect the candidate to ask, and responses to those questions.
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.
Yeah, I really don’t see how this is a sensible interview question. It does not even mention async await syntax. Expecting knowledge on callbacks seems dated.
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.
Same here. I thought that this specific problem is not that uncommon. On top of my mind: say if the endpoint you're hitting is rate-limited. It doesn't even have to be an API call. I think I've probably written something with the same pattern once or twice before.
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.
I could write a solution to this pretty quickly, I’m very comfortable with callbacks in JavaScript and I’ve had to implement debouncing before. But this interviewer would then disqualify me for not using AI to write it for me. So I don’t understand what the interviewer is looking for.
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?
If you don't care about the order of requests then you can just set up a flag to denote if a task is running, and keep rescheduling the other tasks. Something like
let isProcessing = false;
async function checkFlagAndRun(task) {
if (isProcessing) {
return setTimeout(() => checkFlagAndRun(task), 0);
}
isProcessing = true;
await task();
isProcessing = false;
}
should do the trick. You can test it with
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);
BTW, for 4 scheduled tasks, it basically always keeps the order, and I am not sure why. Even if the first task always runs first, the rest 3 should race each other. 5 simultaneously scheduled tasks ruins the order.
I tried this at work but ran into issues where if the server had some error or issue or took longer than expected, the job queue grew too large and caused OOM issues. I had to turn it into a manual list in order to debug the problem, though.
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 expected this to be the answer. I guess the interview is not necessarily for JavaScript programmers, but this seems like the correct solution. It brings in some facilities for dealing with errors, too.
This is not the worst interview question I have seen, but it sure could use some improvement.
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 think also trying to work around a faulty server with client code is a bit weird, I could see it happening in practice but my first instinct given this interview would be to insist the server should receive some attention first, or if it is impossible at least this queue should be implemented by another process or machine near the server side.
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.
echoing the other comments about this being a rather terrible interview question...
> 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 think we all have but that doesn't change that this is almost exclusively a js specific interview question with a very js'y solution to the point of hammering in a imagined "js land" api.
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.
The proper implementation looks kinda bulky to me. Are you not allowed to use promises? Feels more like a naive solution for anyone who has few months of experience with javascript or is it cheating?
You'll need to flatten the promise periodically if you use this approach, otherwise your performance will degrade a bit each time you enqueue something.
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.
If this is given in Javascript, I'd rate the promise solution higher since a Javascript job involves a ton of promisified async code like this. If this is given in C or pseudo-code, then for sure a good ol stack+flag+loop is looking good enough.
I actually tried to use this pattern to make an audio controller interface much nicer. If you get a long enough queue, you'll start to run into errors (I'm forgetting the exact message, but it was similar to a maximum recursion depth)
This most likely happened because you had a queue operation which started another queue operation so a recursion was created which consumed every bit of memory it had available.
In context of JS this kind of promisified async code is intuitive and this pattern is quite common in various projects and libraries, but the solution in C-like pseudocode of course looks more readable for general programming public.
This interview starts off with the interviewer saying it's going to be in JavaScript, and then introducing a piece of code that's clearly not JavaScript:
Eh, the implementation is all Javascript and can be approached in any language. They're just providing function signatures with types so the candidate knows what they're working with.
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.
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!
Might be a whoosh, but really don’t understand the idea of seeing the interviewer as an adversary. Stress in interviews comes from many places but honestly one of the roles of the interviewer is to bring it down.
I think maybe the problem being alluded to is that a lot of interviewers aren't that good at this and instead give off vibes that play up the "I'm judging you from a default presumption that I'm more competent than you" angle.
(Really, it shouldn't be surprising that most technical interviewers aren't that competent, since they usually aren't selected for it.)
Oh god. I’ve met some seriously incompetent people when interviewing - to the point where I’m glad they are the one conducting the interview cause I never want to work with them. I’ve actually finished an interview where I was the candidate with “thank you, but I don’t think this is going to work out”.
To be clear, my point is more that lots of people who are competent at their core jobs and would be perfectly fine coworkers suck at interviewing (but are pressed into service doing it anyway).
Why would anyone agree to participate in interviews then? Do we then force developers to conduct interviews? If so, which ones? The superstars or the ones on PIP? You can see where this is going..
> 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.
I have worked in software development for over 35 years. In that time I have found that the most proficient teams are based on having smart people working in teams that get along well. We’d probably call that emotional safety today, but previously, we just said that everyone worked well together. I don’t know what jobs require interviewing for such a specific response, maybe I’ve never needed that skill set on my team. Intelligent, small ego, team players have been the best teams I have worked with, and I’ll continue to hire based on my gut for those individuals.
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.)
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?
Another thing is that the article emphasized that it's single threaded. That by itself guarantees that there will only ever be 1 inflight request, since calling the send() function will block until the request completes, and the callback is called.
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.
it is too abstract to say for sure, but send might just block until the request is handled off to the next layer (for example succesfully written to the OS network socket buffer), so unless the server carefully closes its recv window until it is done handling the request[1] , no, I wouldn't expect send to block until the server is done handling the request.
[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.
Yeah that confused me at first too. They seem to be treating send() as if it has the same behavior as a setTimeout() call. If you think of it that way, it starts to make sense.
You're absolutely right - the naive implementation has a logical flaw where the queue would always remain empty since tasks are only added when the queue is non-empty, creating a catch-22 situation where the queue can never grow.
If I were interviewed by someone presenting me with this task, I would spend a bit of time helping the interviewer clean up the problem and try to get to where they can explain what they want with just words. Clearly.
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.
I've conducted a fair number of interviews. At least one of the problems I pose to candidates are to test if they will ask questions that clarifies what I am asking for. Because being able to articulate both what you want to accomplish and what the non-negotiable constraints are, is a key skill. The more senior you are, the higher this part of the interview gets weighted.
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.
> 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.
I am kind of shocked you have never had to do this, or that you think it is unreasonable to ask. Sure, it is totally reasonable to ask questions about whether this is standard practice, especially in the real world. But an interview is an environment where you are given the constraints and obviously there isn't time to explain every detail about why something is the way it is.
Yeah, we do want the server to be fixed–there is a team working on it, and they'll have it ready next week. But we need something to work now. That's the where the interview places you. If you are going to be the person who values purity instead of just doing the job when the constraints actually call for it, are you really selling yourself as a good candidate?
Turn the argument on its head: why is it reasonable to ask someone who presumably knows better to waste time trying to solve a server problem on the client side? And why would it be unreasonable for a candidate to reject the premise and suggest a better solution?
(I often pose problems to candidates where challenging the given premise IS the point. You want people who will speak up)
I've spent perhaps a couple of decades designing and implementing various forms of distributed systems, and there are good reasons to avoid trying to hack your way out of trouble by requiring clients to behave a certain way. You will always have less control, it is almost never any easier than fixing the server side, and it doesn't actually address the root problem. You start at the end where the problem is instead of introducing hacks that run the risk of becoming long-lived.
You can always put something in front of a misbehaving backend that can compensate for the problem on the server side. In fact, this common enough that there exists a rich fauna of components that are used to address these kinds of issues. From more generic load balancers to more advanced application specific middleware. I've worked on perhaps half a dozen such systems and I've designed and implemented two of them from the ground up.
So yes, when people start trying to solve server problems by hacking the client, I tend to assume that they probably don't know what they are doing. And if they're not open to the possibility that they are wrong, why on earth would I waste my time working for them? Let alone try to convince them? Life is too short.
You do understand that this is a one-hour interview, not an extended discussion about your software's architecture, right? Are you going to also call out the fact that this doesn't support a hundred million concurrent users and multi-region failover either?
>> If I were interviewed by someone presenting me with this task, I would spend a bit of time helping the interviewer clean up the problem and try to get to where they can explain what they want with just words. Clearly
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.
> The interviewer would fail you because this interviewer
> wants to feel superior and more powerful
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.
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.
the async part isnt very exciting, but its the callback after the entry has been through the queue and worked on.
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've implemented multiple production versions of this problem (but not in JavaScript)[1], so maybe my view of this problem is miscalibrated...
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?
It's too hard because the variations you could add to it (multi threading) that add enough depth to make it hard make it too hard, in my opinion. If you look at the implementation I linked in my previous comment, it's fully lock-free, which is pretty unreasonable to expect from anyone who isn't already familiar with lock free concurrency. On the other hand the version with a lock is basically identical to the single thread version. Asking for the two-lock queue is also a bad interview question because it's not something you'd reasonably expect someone to derive in an interview.
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.
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
I've seen somewhat similar things in embedded development, e.g. ADCs with a triggered conversion mode that start a new conversion on receipt of a new trigger, abandoning a previous conversion if one was in progress. They fire an interrupt when the conversion completes. Not in any way buggy or unexpected, ICs generally either can block or can immediately respond but can't queue multiple requests.
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.
After some years applying for different positions, I started asking receuiters about their hiring process and straight out dropping out when there were technical tests like this.
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.
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.
> (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.
I did this in the firmware of a VoIP base station.
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.
Well, I had an interview recently where I passed with flying honors the technical interview but they failed me at "cultural fit", which was strangely, the last one in the series.
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.
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.
I would respectfully suggest that this entire approach creates a pathological distributed system, where the client is trying to internally keep track of the state of a server, but without any of the supervision tools would need to do so reliably. (And, as a bonus, it's doing this with a callback hell) What happens if either one restarts/crashes? What happens if you accidentally launch 2 clients?
It’s funny because I have had ti implement “serialized fetch()” a few times recently, with delays and random jitter too.
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).
It’s not tricky if you understand how both work. If you don’t it will be a challenge, especially if you add all the correct error handling and cancelation. Bonus points if you make it work with only up to N tasks running at a time.
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.
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 intro isnt throttling, its request serialization. there isnt some limit to keep your requests to, just that its one at a time. it could go as fast or as slow as the individual requests finish.
its still not a great architecture, but its different from throttling
> But that server is faulty!! If it has to handle multiple requests at once, it starts to break down. 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
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.
“… 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.
These are multiple assumptions
"This queue is only on one machine and on one thread", what's the real world use-case here? Not saying there's none but make it clear. I wouldn't want to work for a company that has to think of some random precise question instead of e.g. "when would you not use mysql?"
Posting interview questions on Hacker News is so funny. Regardless of what the question is half the people will tell you that it's an interviewer ego trip that has no relevance to the real world while the other half will explain how interviews are actually a total waste of time and how carpenters do it right (obviously, without actually consulting how carpenters do their interviews). If the question has anything in it that's not an array then it's called "Leetcode" and clearly FAANG-engineer biased. If it has any other form then it's too confusing and too contrived. Of course, the end result of this discussion is that the author is a horrible employee at a horrible workplace and nobody should ever want to work with them. Thank god that 'randomuser123 was able to figure out that they were telling on themselves and explaining that if they were in this interview they'd stand up and tell the interviewer how their entire architecture was wrong and they should be ashamed for even asking the question instead of changing the world around them. And then everyone claps.
Easier to write. But there is a case to be made that code which can be understood without understanding somewhat esoteric language internals is superior.
I guess "esoteric" is in the eye of the beholder, but Promises seem a lot easier than the old callback style we used to use for asynchronous operations.
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"
As a general comment, I wish hiring managers found some other outlets for their enormous ego and insecurities than the process of hiring of software engineers.
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
> 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.
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.
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.
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.
In the interview, am I allowed to fix the server (which apparently "breaks down handling concurrent requests") instead of working on this silly programming exercise?
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.
One of the best interview questions I ever received, I was asked to explain how something I liked worked in detail. Could be literally anything, just break it down step by step. I was told I could use the whiteboard but didn't have to.
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.
Heh heh. I dont understand what the fuss is about, AsyncQueue is kinda cool in JS. I use it, from time to time, to implement async generators that can be iterated over with for await.
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.
Their "proper implementation" lacks sufficient error/exception handling around the callback() call. It'll become permanently broken if it throws anything.
Yeah I think the premise is a bit poorly designed, I would just wave it away and focus on the queue. The coding problem itself is pretty well defined. And I think the premise is intentionally presented kind of poorly defined, which makes me think it's meant to not really be part of the problem.
> 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).
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.
I spend more time than my interviewees on the question to try to solve the problem every way that it is possible to solve it. If a candidate picks any of the solutions they pass. If they pick a solution I didn't know of they also pass (with flying colors) but I fail.
"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.
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.
This is a complete nonsense. OP has invented a tricky technical test for themselves which they have spent long amounts of time thinking about.
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.
It's a great question if you want a Node.js developer. But what if they come from a Go or Java background.
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.
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.
It just doesn't feel like this is right.
It's because our profession seems to attract a number of intellectually insecure people who thrive on these little puzzles and the associated minutiae as a means of feeling a sense of superiority. They all think they've figured it out: the best way to tell if someone is a Good Dev or a Shit Dev. Of course, administering the test, there's no way they could possibly be anything but the Good Dev. It is embarrassing. Don't believe me? Why can't they help but blog about it?
We have FAANG to thank for this. They pioneer counterproductive interview questions (remember puzzles?), and the industry just copies these trends, like zombies.
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?
> We have FAANG to thank for this.
Not entirely, though FAANG companies certainly didn't do anything to help make it better.
I'm 51 and have been a professional software developer since the early to mid 1990s and tech interviewing was already a strange hazing ritual disaster before FAANG existed.
I distinctly remember interviewing for a QA position in the 90's where I was asked how I would test a soda vending machine. I was dinged because I didn't mention that I would make sure the sodas were cold.
Actually Microsoft started this in the 1990s, long before FAANG was a thing. They just all adopted it.
“Why are manhole covers round?” “How many dry cleaners are in the city of Seattle?” were both infamous Microsoft interview questions.
Previously known as "Fermi questions"- commonly asked of undergrads and grad students in quantitative fields.
I think quant finance is similarly bad
The real problem: How you accurately evaluate a candidate without these questions? I dislike them as much as the next person, but I don't know a better way. Literally, all the best tech firms and ibanks do it. They pay the most and are most profitable. They must be doing something right. The real trick is finding a "fractically complex" question with many levels. The one in this blog is pretty good! No candidate can solve it perfectly in the allotted time, but you can have a good discussion about the "edges" of the problem -- where good candidates shine.
How do you accurately evaluate candidates with them?
It's an artificial test that doesn't reflect your working environment at all, and so you're not actually getting to see what they'd be capable of doing faced with real world coding work.
It's a discriminatory practice that is proven bad for a lot of neurodivergent candidates, like folks with autism, or ADHD.
You end up eliminating a whole lot of good candidates just by the structure, and then end up picking up a candidate who happens to do well out of that small subset and it still won't stop you from hiring developers that are terrible.
One of the worst developers I've ever worked with will absolutely sail through leetcode exercises. He's brilliant at it. Something about his brain excels in that environment. If only work was like a leetcode interview, filled with leetcode style questions, and someone watching and evaluating his work as he did it, he'd be a fine hire anywhere.
He can't write actual production software to save his arse, needs deadline pressure breathing down his neck, and then what he'll produce at the last minute (always technically makes the deadline), will probably work but is the most unmaintainable nightmare that needs to be rejected and redone by another developer.
I have had the exact same experience with the exact same kind of person. We used to be in the same team for years and after we collaborated once, I absolutely hated any work interaction related to his him or his work. Outside of work we got along well, he was fine, socially stunted, but that's OK.
When the layoff time came, everyone had to scramble to move by themselves to a small selection of teams. The second I heard that guy was interviewing for the same team as me, I had gotten an offer at that point, I told the hiring manager, me or him. That's how bad working with those kinds of people can be. He ended up elsewhere and I'm still in that team. I just could not deal with him anymore. Perfect interviewer, but couldn't write production code to save his life... He's still employed by the way, bumbling around from team to team because the consequences of his incompetence take months or years to feel...
>> They must be doing something right
What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices. Likely other hiring practices would have worked fine as well.
>> Literally, all the best tech firms and ibanks do it. They must be doing something right.
Reasoning by first principles isn't exactly the software industry's strong point.
> What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices.
Agreed though I'm not sure I'd be as generous as you are when it comes to their business models being that great in absolute terms.
Strip away all the confirmation and survivorship bias and IMO it is pretty obvious a lot of the success of tech in general for multiple decades running was almost entirely the result of the free money lottery system funded by zero interest rates.
It's always
- someone else's money (zirp, middle-eastern sugar daddies, juicy government contracts)
- adverts
I really counsel everyone to stop thinking like this. The appealing to authority doesn't work when you are talking about different sized businesses.
All the best banks and tech firms do a lot of things that could be categorized as wasteful, useless, inertia maintaining, etc, adopting their practices without a thorough understanding if it applies to your business is plainly just stupid.
Your business is not structured like those big business, you are not as anemic to risk as they are (otherwise you wouldn't even create your business in the first place), you don't have their cash, you don't have their ability to spend an enormous amount of time hiring every single person because your profits cushion you from all your dumb decisions.
This is my own experience but I find the evaluation on interest and intellectual curiosity to be more validating long term than being able to rote memorize problems.
Edit: To add some color, I want a candidate who is excited to program, I don’t care as much about their ability beyond having the basics which I find pretty easy to figure out in an initial conversation. Candidates who are excited for the opportunity are generally the ones who I find to excel in the long run.
If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.
In my experience the signal is pretty strong.
Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?
Gut feeling based on the generally very high competence of my colleagues when I was at Google.
I trust they were really competent, but it's a bit depressing that these competent people will need to go through the leetcode rituals and 5-10 interviews to get a new job at Meta, Netflix, AWS or adjacent companies. That's actually the point of the original post; you are never judged by your (years of) experience or even your past companies, only by the results of a test from a random person/company.
I disagree; I don't think a full day of interviews is a huge price to pay for a FAANG job. The stakes are high for the employer, the rewards are high for successful applicants, and if you get to that stage, you've already passed a lower-stakes phone screen.
Put yourself in the employer's shoes: You want a high-quality SWE, you're prepared to pay them top dollar, but if they turn out to be not so great, it's expensive to get rid of them. Would you be satisfied by years of experience at other companies by itself, when you know that (like in many job markets) there's a big market for lemons? I wouldn't. I would want to see the candidate demonstrate some specific skills -- ideally the skills they'd be using day-to-day, but if that's not feasible for time reasons (it usually isn't), then adjacent skills that generally imply (though are not necessarily implied by) them, like recognising the shape of a toy problem, and knowing and applying the right algorithm to solve it.
I am not commenting on the interview effort-salary ratio, but the fact that credentials and experience mean nothing to the tech industry, also comparing to the rest of professions. I mean working in Google/Meta/Netflix, is like working on the best hospital if you are a doctor, in the best construction industry if you are an engineer, to best law firm if you are a lawyer, etc. Imagine having to pass a leetcode or iq test everytime you want to move to the next one. I definitely know that my cousin, who is an exceptional doctor in Greece with only 10 years of experience, laughs about it.
I think it should be the other way round: In an ideal world, everyone, including doctors and executives, should expect to have to demonstrate their skills when applying for a new job.
It's just unfortunate that there isn't (TTBOMK) an easy way of measuring, in a few hours, how good an executive is at executive-ing. Which is why the field is crammed with useless pretenders who nevertheless manage to flit from job to job, soaking up fat compensation packages before their incompetence is exposed.
I'm curious why there doesn't seem to be the same market for lemons for doctors. Or is there? How does a person actually know if a doctor is good?
I am glad that you mentioned Google. At this point, their interview process is legendary. It is so good that many other companies have tried to copy it.
For me too, anyone that does horribly, bad signal. Anyone who does perfectly, bad signal.
I've found that looking for mediocre and sub-par results will give you professionals that spend their time getting good at the profession instead of getting good at leetcoding.
I have never and will never hire code monkeys. AI already takes care of that.
ask deep technical questions and evaluate the response.
I've had better success, by a wide margin, doing this, than any code challenges ever gave.
I don't know why the industry is so averse to this, it really does work, and I know others who also swear by it.
You can find the bullshitters pretty quickly even in this ChatGPT driven world
I think the pushback here is from the following:
1. Because it is so dynamic and subjective, it is very hard to systematize this kind of interview, which makes it very hard to work into a repeatable or scalable process. The need to compare incoming candidates is an unfortunate reality of the industry for many companies.
1b. It is basically impossible to control for bias and things like "was the interviewer having a good day".
2. This kind of interview overly rewards charismatic speakers -- this is partially ok, depending on the role, because being able to speak accurately and cogently about the work you're doing and are going to do is part of the job (especially for staff+ engineering). It isn't necessary for all jobs, however.
3. Many people aren't good at driving this kind of conversation for whatever reason. When it goes well it goes well but when this kind of conversation goes poorly it reflects badly on the company.
4. People Ops want more control then this gives them, across many dimensions.
"Write some code to solve this tricky problem" seems like a deep technical question to me. Can you give some examples of what you have in mind?
define "tricky problem". Given the nature of something being tricky, it could well be too heavily reliant on the 'trick'.
I had in mind the problem given in TFA, but I should have been explicit about that.
I think it's probably too hard as an interview question, but also that it actually is a somewhat realistic problem that I'd expect a senior programmer to (eventually) puzzle out correctly. (As opposed to, say, the archetypal bad interview question, "How do you swap two integer values without using a temporary?", where many people happen to already know the trick, and if you don't, you're unlikely to figure it out on your own in the space of an interview.)
not OP, but i was once asked from the HTTP layer down to PHY layer (a role for embedded system)
> The real problem: How you accurately evaluate a candidate without these questions?
The fact this question needs to be asked really reinforces parent's point.
Perhaps we should examine at how other respectable fields validate their candidates and follow suit?
If we don't have any form standardization for this stuff, I think that speaks more to the lack of maturity of our field than anything else.
Do other fields really have this figured out?
I guess bridges, buildings and houses generally don't fall.
Is that only due to hiring though? It seems more like physics doesn't change. And people who can do audits and inspections are probably pretty good.
I did an audit for my software at work. It's like talking to a child. Talking to a home inspector is way different experience.
> Literally, all the best tech firms and ibanks do it.
So do all the worst - look at the extent to which hiring this Soham Parekh fellow has become a badge of honour instead of abject failure.
Hiring that guy is a badge of honor because admitting otherwise would be to admit that the interview processes have nothing to do with the job, thus the real incompetence here is with the companies and people following that interviewing style.
Instead of correcting themselves, those interviewers chose to dive deeper into delusion.
Accurately evaluating a candidate is impossible, but surely asking a candidate these questions will yoeld a lower quality worker than if you ask them something related to the work they might do.
I disagree. I always go back to the blog posts that Joel Spolsky wrote 20+ years ago about his theory of hiring. The primary goal is to avoid bad hires. Even simple tech problems can easily eliminate (or rank) many software devs. As someone who regularly interviews candidates, I am blown away how bad are many of them.
I think a lot of fields of engineering have analogous questions actually. EEs ask to explain a circuit or draw a new one. Mech Es ask to design some piece of simple hardware with a clever catch. Interviewing is just hard, it’s impossible to cover breadth of knowledge in 45 mins so we end up with little brain teasers.
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.
Lawyers have law school after a degree, a bar exam, legal liability for malpractice, and ongoing licensing requirements.
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.
The difference is that if you fail medicine, it’s ok (it’s hard). But if you fail to get a job because of the stupid “async queue” author’s problem, well, that’s depressing.
I'm not so sure. Failing your residency means your medical career is basically done, and you have to basically start a new career from scratch in your late 20s. Chances are you'll have debt from not just undergrad but also med school.
By comparison, failing a leetcode interview means you've got to find a new company to interview with.
How's failing medicine not depressing!
failing medicine is depressing in the original sense of giving personal depression, failing stupid leetcode and not getting job is depressing in the more modern sense of the world is stupid and not well-organized.
That's like, your opinion. Any argument you can make for leetcode, one can make on the medical certification exam as well.
I know its not a popular opinion here or elsewhere, but since these interviews are so standard, why don't we have a uniform standard body where I can get a licensure, do yearly trainings etc as a software engineer? It would solve the same problem something like the CPA exam does.
For the same reason we have 2137 libraries, frameworks and languages that do the same thing - because everyone thinks they can do it better.
I don't think the reason we have so many libraries / frameworks is the same line of reasoning that hiring is copy pasta throughout the industry
I think we do with OMSCS.
Perhaps the bar should be as high as law and medicine if we want people to take our industry just as seriously.
Nope. In my opinion Wild West in software is much preferred model. If one wants to create software and sell it there should be no barriers. It is one of the the very few fields that give chance to simple people with no money to break out and live decent life.
Tbh I think it depends on the domain you are coding for. The field is so diverse across many different parts of the economy. E-Commerce web app sure go for your life -> software for controlling some life support system... yeah maybe I want someone with qualifications and audited standards thanks.
Life support and controls system should absolutely have a high standard, but even E-Commerce should have a decent bar. If you're handling my money I expect you to be an adult.
I develop software for various areas. The ones that come anywhere close to regulated areas surely gets audited.
>"software for controlling some life support system..."
I believe there are processes to ensure this kind of software is safe (obviously to a degree).
Sure. But audits/processes only catch up to a point. In the end the buck stops with a professional. That's what most "professions" are. They aren't just a service -> they are an accreditation with some recourse which gives them prestige/social status/etc if they have years of experience (i.e. despite the risk imposed on them as a professional they have survived/thrived).
>"In the end the buck stops with a professional."
Where did you get the idea that "professionals" do not fuck up. They do it just as much as mere mortals.
[dead]
Just make sure to save up before ageism kicks in.
Its not common that people in our industry don't have bachelor degrees anymore. Its also not an industry where I routinely find the majority of people come from lower economic backgrounds etc.
I think a fair compromise would be not to require specific degrees to test, but rather a service fee (which could be sponsored) but I think a similar rigorous standards based exam would do wonders for our industry, even if it trims who can enter it on the margins
>"Its not common that people in our industry don't have bachelor degrees anymore. Its also not an industry where I routinely find the majority of people come from lower economic backgrounds etc."
It does not matter what you "routinely find". Live and let live. Person has an inherent right to make living however they see fit unless it actively harms others.
If you are so concerned about degrees why not to start with the one of a "decent human" and require it from politicians. Those fuckers affect us way more than any software and and mostly walk free no matter haw badly they fuck someone's life
Your attitude is completely off-base. Would you get treated by a doctor who was not recognized by the AMA? Would you hire a lawyer who was not called to the bar, or an accountant who was not chartered or equivalent?
Yet somehow a high school education is sufficient to write software for a 4000 lbs vehicle moving at 60 mph.
>"Yet somehow a high school education is sufficient to write software for a 4000 lbs vehicle moving at 60 mph."
Cut the BS please. Safety critical software gets audited and other measures are taken to insure it stays safe to a degree. However if one wants to write software for let's say music synthesizer the only thing that matter is the person ability. In this case I would look for experience, list of completed projects and other relevant info. I would not give a rat's ass about their diploma. Some of the best / successful software was often created by domain experts who learned how to program.
> Cut the BS please. Safety critical software gets audited and other measures are taken to insure it stays safe to a degree.
Oh? BS is it? Pray tell who's auditing Tesla's software? Or Waymo's for that matter?
I am sure Tesla can show you all the licenses and creds you'll ever need
because our industry would improve massively if we actually removed a barrier to allowing standardized licensure
I also never said it should be held behind a degree, instead I said a fee, which could be sponsored. No degree required, though one certainly would help I imagine.
We live in a society, and we should think beyond the individual in terms of benefits. This would be a big win for society.
>"because our industry would improve massively if we actually removed a barrier to allowing standardized licensure"
I call BS on that but each one of course is entitled to their own opinion. Go get your license if you don't have one already.
>"..instead I said a fee, which could be sponsored. No degree required, though one certainly would help I imagine."
We have enough mafia type bloodsuckers. My take on those money collectors: go fuck yourselves.
>"We live in a society, and we should think beyond the individual in terms of benefits. This would be a big win for society."
And who would be thinking? Our masters looking to squeeze yet more money from people? Enough of that "won't anyone think of children" vomit.
What would be on such an exam? Pseudocode, logic puzzles?
Certainly not specifics on any particular technology, right?
those generic screener questions aren't technology specific. Data structures, algorithms, system design (the top 3 that show up in interviews), none of which are technology specific.
Throw in best practices like TDD, code security, and architectural patterns and I think you could hit all of the most common non technology specific domains that cover it
Many people in software have passed through similarly hard gates in the past. An engineering degree is harder to attain than a law degree for instance. The question isn't about these gates, it is about the interview practice once one is already through. Do law or medical interviews include questions unrelated to the work that they do in a reasonably analogous manner to leetcode? Maybe they do. Perhaps hiring is broken in all fields.
> Many people in software have passed through similarly hard gates in the past.
I didn't. I dropped out of school to work at my first job. That's different from a doctor, nurse, lawyer, CPA or PE who have to meet an industry standard.
Right, certification gate keeping doesn't exist for software. I have an engineering stamp but never got a chance to use it.
The problem is, an engineering stamp or comp sci degree doesn't seem to be particularly predictive of dev capability.
to put it another way there isn’t this much focus on show me you know this weird problem that I’ve been studying for 5 years as well me, your 5 min timer starts now
Oh yeah. Spoke quite a bit to a doctor who wanted to get into a speciality last year. That shits hard. Intersection of mentally hard, hours demanding and high bars to entry.
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.
> does anyone else get embarrassed of their career choice when you read things like this?
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.
Leetcode has nothing to do with actually programming a project that lives long enough to deliver value.
I used to give a code review task, of some particularly egregious python code. I'd provide all help with the syntax, and emphasise strongly upfront I don't expect them to know python or its syntax. It has proven to be a low stress task for candidates. They're not trying to solve a brain teaser, they're just doing something that's going to be part of the job. Reading code, understanding what it is doing, and providing feedback to make it more maintainable.
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.
The most "refreshing" interview I had was one where the guy had a list of like 100 questions about C++, and he would just go through and ask "do you know what SIMD is?" or "are you familiar with smart pointers?" or "tell me about templates" (most were less open ended than the template one). If I responded yes, he'd follow up, and it was more of a discussion. If I said no he'd just move on to the next one (sometimes I'd ask what it was and he'd explain).
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 build teams in their own broken image of what a good programmer should be, and then get to manager and director and mould entire companies the same way.
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.
The higher layer of people in our industry aren’t subjected to those questions. They are evaluated and get jobs more like in law and medicine, ie based on connections and track of record.
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.
Of course it's not right. Let's be honest, our profession is in the era where software engineer = factory worker, and the worst part is that we have been playing music chairs right for the last couple years. So yeah all these professions have some steady status/wealth/qol progression and upgrade while people gain years of experience, while in software development it doesn't matter how many years of experience we have, which companies we worked on, their sector, whether your company is using the saas we were working on, etc.; we are going to get judged by trivia questions and leetcode.
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.
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.
I had lunch with a friend who was trying to get a job at a law firm and they told me that their interview was just vibes and if they asked him actual law questions it would be refreshing. So maybe things aren't necessarily greener on the other side?
Other fields definitely involve similar lines of questioning in interviews. Medicine and law are special cases because they have their own set of standards that must be passed before you can even get an interview, but private equity interviews definitely include case studies/technical questions in a similar vein to the one shared in this post.
I heard that private equity does the equivalent. They show you balance sheet of a potential takeover candidate then ask for feedback. I assume that good candidates will need to do some Excel to answer their questions. Also, interviewing for trader roles at ibanks is similar. Show a trading scenario, ask what they would do and why. I guess law must be similar as well.
The difference to me is this: they're real analyst questions that you will have likely dealt with before in some detail, and not an obscure algorithm I maybe haven't seen since college or a leetcode not particularly real world presented or relevant brain teaser.
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
> But does anyone else get embarrassed of their career choice when you read things like this?
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?
> 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.
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.
> I'm sure there has to be a mismatch between what we define as "those questions".
When I said "these questions" in my comment, I meant the questions in the article. That's what this discussion is about! Those are not inverting linked lists or traversing binary trees. They're about networking, asynchronous actions and time outs.
And yes, I do deal with those things all them. Maybe not every day, but certainly multiple times in each project. Ever had to deal with a timer where it might still be triggered even after you've cancelled it [1] (because its underlying implementation has already fired but the callback is still waiting in the completion queue)? Or even trigger twice because you then re-set it while the first callback was still in the queue? That's just an example, but that's exactly the sort of fiddly condition that permeates every corner of a heavily async or multithreaded / distributed system. If your work involves that then it's totally fair to ask about them in interviews.
[1] https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/...
> ... I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. ...
Well, I agree, that's bad. But, as you say, the same questions can go either way depending on the interviewer. The very reason that I mentioned these being "discussion based" in my comment was because I took it as read that silly tricky questions are bad and to make the point that these questions don't seem to be designed for that.
Are we not allowed to ask technical questions in an interview just because some interviewers are bad? Should we be "embarrassed" about the questions in the article, as was said in the comment that I was replying to? That was what I was objecting to.
Which part, the fact that you have to answer such questions to get a job? Those other fields are more established and have formal barriers to entry.
Agreed, this is just terrible for the field as a whole it’s like we’re regressing or something
When I started writing code for a living 30 years ago, we were mostly left alone to solve problems.
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.
Don't know how many experience you get but other fields have a lot of these. Accountance have certificates, finance / quant have to solve headmaths type of problems.
> It just doesn't feel like this is right.
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.
My favorite interviews I have taken:
* 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.
Long ago, I worked for a contractor company, so my colleagues and I had a lot of interviews to get sub-hired. As we had many of those interviews, we got pretty good at them, and we shared our experiences, knew popular tricky questions (like "swap using [place here any constraint]") and had names for different types of interviews. "Kick in the balls" was one of them, tricky questions which showed nothing, except that somebody solved that particular narrow problem or was already familiar with that question.
Having that experience, I know that the only reasonable interview is an open conversation. What was your last project? What was the architecture? What was problematic? How did you solve that? How did you come up with the solution? And so on. The candidate is relaxed, drinks coffee, and talks. After 1 hour, you know who you're dealing with.
If there's time, a pair coding session is informative. There are many small hints, like using shortcuts, that give away pros.
I have tried the first two things in that list. I haven't tried the third. I would need to think about how to do that in a way that is general enough that it can be re-used across candidates with different skill sets. I like the idea, though. Thanks for sharing it.
Its very specialized, since I was hiring for data roles I used hex.tech with some examples and it was great.
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.
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?
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.
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.
> But does anyone else get embarrassed
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.
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.
[dead]
When I interview a candidate, I focus primarily on what they've done. Ideally they'd have a body of work online that I can view beforehand. Then I go through a high level system design and have a collaborative conversation. Last, I give a pretty straightforward coding question, whose purpose is only to make sure they aren't full of shit, which often they are.
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.
I follow the dame process. I explain beforehand what kind of questions will be asked, and emphasize there are no tricky questions, that we are just curious about their experience, area of interest, preferences for designing ode, how they tackle ode quality and user support, etc.
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.)
> didn't have anything public on github/company gitlab/dockerhub/researchgate/
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?
As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain that without too much trouble.
Asking them about decisions in the project, issues, pros and cons of tools, etc., normally clarifies whether they understand things or not.
And as I replied in the other comment too, unfortunately if there is another candidate with very similar profile & good answers, then I'll give my technical assessment to the manager of the position, and it'll be up to the manager and humans resources to choose based on risk to the company, what they can see from public papers/conferences/repositories/etc.
In some cases, even if the work is not public, they can tell us what projects they worked. I work with climate models, so if they mention they don't have anything public, but they were using IFS, FESOM, ICON, SCHISM, or another model that I know/work with, then I'd direct questions on that model, to check what part of the model they worked on or used, who they worked with, etc.
For me not having something public is not a blocker for hiring. Just something that simplifies the hiring process -- although, lately I've had a lot of candidates with many personal projects, no branches, no pull requests, not showing experience with Git, etc. (i.e. in some cases it seems some people try to create many repositories just to show that they have something... which can be a red flag too).
Great question. I'm okay with someone who doesn't have public code, although they will have to work a little harder to verify their skills match their story.
You have some public repos. That's plenty. Even some gists will work
I tell people all the time, if you want to make it easier to get hired, put some work online. This is especially helpful for those without great credentials or history. Take advantage of this, as it's not possible in many other professions.
Agreed. Another thing that helps is writing. If you have a blog, it helps tremendously as it's possible to learn a lot from an engineer when the posts contain some thoughts about what that person learned or worked on, some opinions, techniques and tools used, etc.
Even these Linkedin posts are fine, as long as it's not an ad to some tool, or just full of buzzwords.
The kind of "behind the trenches" posts are great too, to explain something that happened in a project, a challenge you had, how you debugged a problem. This saves a lot of time in the interview as I would read it all and use that to discuss with the candidate.
What I've done is create one github project in my repo that is public, well-architected, implemented, tested, and commented. That's what I share if somebody wants a code example. I wrote the whole thing from scratch based on personal knowledge and some documentation (pyparsing and SMILES strings). I wrote it while working for a company, and went through their open-sourcing of personal work process.
I guess they just don't want to hire/interview workers who don't have public work. Maybe they pay very well and can be selective with their candidates, especially in this market. Or they live in some SV bubble where every workers has public work so it's the norm where they live.
Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
No bubble here, I think. I'm also based in EU, Spain, where job market is super competitive right now, and it's quite hard to find candidates.
As I said, it doesn't need to be only public repositories. If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries. If the answer is no (happened just a few days ago), then I ask what they used. I expect them to say something like Artifactory, Nexus, a directory on a server or HPC, or just explain why they didn't need a registry. For me there is really no wrong answer here. But if they reply they don't have anything public, and have no idea what's a container registry, then that's probably bad -- this is what I think OP of this thread meant by eliminating candidates that are full of---.
> Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
My wife also works here, and she's a recruiter in a EU company, in cancer/research. Most applicants won't have things public in that case, but they can still explain things. If there is a candidate with similar profile, that managers liked, and they have a lot of good work, public, then it's up to managers. I just explain what I saw in the repositories, whether I'd work with the candidates, and the managers hiring choose based on risk for companies.
As you are based in EU, you probably have the same problem that the hiring process can be expensive for company, and risky if you eliminate candidates, and have to go back during the experience/trial period of candidates.
> job market is super competitive right now, and it's quite hard to find candidates
Sounds like a contradiction. If it's super competitive shouldn't it be easy to find candidates?
> If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries.
How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?
Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.
So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises
> Sounds like a contradiction. If it's super competitive shouldn't it be easy to find candidates?
I know, it should be the other way around. I asked some locals, and so far some of the best answers I got for this are that the best brains here are abroad, at the Netherlands, Germany, etc.. There's a lot of applicants for every position we advertise (especially if we need someone from DevOps or Web -- not so much for Fortran, Scientific Programming, but that's normal).
But most don't pass the first filter. We try to select those that fill the basic criteria, even if they don't fill all the boxes (it's alright to learn on the job for us), even select some that do not pass to call for a short interview with HR or even with manager, but it's quite hard to find good candidates.
> How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?
It's quite common for some companies in my current field, earth sciences. Many companies have public GitLab servers, or host their own containers (e.g. Mercator Ocean International, DKRZ, ECMWF, etc.).
As I mentioned in other comments, I'd interview someone that doesn't have public repositories or containers anyway. But in the end, if there are other candidates with good CVs, and interesting projects public on GitHub, etc., or if they collaborated to good Open Source projects (Dask, Xarray, Singularity, Jenkins, Python, fortran, etc.) changes increase.
> Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.
I worked in banks, insurance, credit bureau, telco, and government. In most of these the work was done in private CVS, Subversion, or Git servers.
But in most of these, we used Open Source projects, and normally we were allowed to send contributions back upstream, when we found bugs in numpy, python, etc.. There were some companies where I couldn't contribute, so I can only explain the systems I worked, and the tech stack we had.
> So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises
We hire people without public repositories too. Having worked at FOSS projects/enterprises definitely helps.
It's the same as the degree you have. In the end it may be an advantage depending on the company. I, particularly, do not care much if someone is coming from physics, mathematics, economics, biology, or even architecture (we just hired an architect that enrolled in a CS degree in Portugal to work with data pipelines/NetCDF/xarray/etc.).
As long as the person has the technical knowledge required for the job, and some experience if needed, that's fine by me. But I worked with manager that only hired those coming from CS.
So even those with good public contributions or coming from enterprise/FOSS, acing a technical test, etc., nothing would help you to be selected when applying for that team.
>or even architecture (we just hired an architect that enrolled in a CS degree in Portugal to work with data pipelines/NetCDF/xarray/etc.)
Out of curiosity how would an architect without pipeline job experience get hired for such a position? Asking for a friend.
In our case we had a junior position in the data team, and advertised it in Linkedin and asked others to spread word to friends/bluesky/etc.
Somehow, that person heard about the position, and was already trying to transition from architecture to IT (had enrolled in an open university course of CS -- online, remote).
We really try to interview as many as we can, give a fair chance to all (ignoring background, gender, etc., focusing on what's needed for the position).
Human resources did the first triage (assessing character/personality [one of those simple psychology assessment tests], level of English, visa/work permit/etc.).
Then the managers for the position (department leader + group leader) reviewed CVs and prepared brief interviews, followed by a final technical interview. That's it.
That person did not have a lot of experience, little visible in GitHub, having only studied IT for a few months, but he was really trying hard. The managers liked his attitude, and believed he was the best fit for the position.
He's now learning Git, Docker, Python, NetCDF, etc. In fact, today we will have a quick chat near the waterfountain/coffee machine as he asked me if we could chat as he had questions about pyproject.toml and building Python packages.
I believe if instead he had showed some projects with Python and NetCDF, and said he was looking into enrolling in a CS degree or take some courses, that could have been a replacement for the CS degree.
So tell your friend to try to choose what s/he prefers (data, programming, performance, DevOps, web, algorithms, compilers, etc.), and try to either create a public portfolio, or study hard so that in an interview s/he can answer questions well, showing some knowledge & interest (e.g. in this case, knowing what's NetCDF is, what's GRIB/BUFR, xarray, etc., even without a lot of hands-on experience could have been an advantage).
> Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
This mirrors my experience as well.
I tend to do some side projects on the side but, seeing as I do them for fun, I don't take them as seriously. I'd hate to be judged based on work like this over something I'd do in a professional setting.
That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
> That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
Yeah, I'd also hate to be in that position where I may be the best candidate for a position but somebody else got it just because they have public projects. But at the end, the managers/HR/technical team/etc. are all trying to minimize risks to the company and projects.
I did this once! I was given a "create Battleship" take-home assignment. Normally, I'd say, "yeah, I don't have time for this". But I happen to really like that game and had never thought of how to model it in code. So I took up the challenge. I spent time whiteboarding classes, interfaces, writing tests... in the end, I had a solid solution. I submitted my code and as I was doing so, I thought, "you know, this really could be handled by a couple of Set data structures. After hitting send, I did a quick follow-up with, "you know, this has a very simple solution" and typed some example code right in the body of the email. I love it when I can't just leave a problem alone. The hiring manager appreciated it too!
Isn't it fun when you can take a game you play and write an implementation (both the game and the solver), thinking through all the details, and at the end, the solution is simple, elegant, and enlightening?
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.
Coding is like sex, both are susceptible to performance anxiety when made to be done in front of others.
It gets easier with practice.
> When I interview a candidate, I focus primarily on what they've done.
I like to hear candidates explain how they understood and met the customer's requirements. The code is only part of the success.
Agree, although this is often an undeveloped skill in newer folks. There are many other things I like to discuss in an interview: past mistakes, things they are especially proud of, times they trimmed scope to meet a deadline, working with difficult people, etc.
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.
I think it's a great idea to ask what someone might have done differently if they'd built one of those bodies of work professionally.
Priorities are often different with experiments and side projects.
I also think why someone built something can be more meaningful than how.
[flagged]
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.
> and more real problem oriented workplace
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
Did you have to do this within 30-60 minutes? Or was it some days long research followed by experimentation and testing (at least the first time)?
I did it in a couple of hours, it's not a difficult problem (but, to be fair, I'm a senior dev)
I’ve had to do a variation of this many times, not because the server necessarily could only handle one at a time but simply down to rate limits.
I agree to a point. For me, what chaffs is the convulted prompt that goes against all my instincts for how to design something simply and clearly.
"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 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.
> seems like a really confusing question
Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.
The confusing part for me is why I’m dicking around with the client when the server’s broken.
Exactly. If I were asked this question during an interview, the first thing I'd say is "why should the client bother with anything more complex than jittered exponential backoff?"
I've dealt with backends that refresh a CSRF token on each valid request and return it in the response as a cookie. In those cases a solution like this may be needed. Not optimal but, we don't always have control over the backends we use, especially then they're provided by a third party.
From a security perspective, it’s axiomatic that you can’t make a client behave in any particular way; we just assume the client is hostile.
I've had to implement this exact logic at work, because we have to talk to devices using modbus tcp, where a lot of devices only supports having one active request per connection at a time. One device we talk to only supports having 5 active connections to it.
I've dealt with low-limit APIs, and I've always considered the better approach to the problem is to create a proxy rather than trust the clients to manage, limit and coordinate themselves.
Then we send all traffic to proxy.service instead of canon.service, and implement queuing, rate limiting, caching, etc on the proxy.
This shields the weak part of the system from the clients.
Makes sense as a broad pattern!
I guess I hadn't considered the existence of generic TCP proxies And I'd probably have concerns around how much latency it would introduce in an environment where we have some requirements on the rate of data collection.
That said our service Does act as a kind of proxy for a few protocols.
Because you only control the client, but you need to integrate with that broken server of a third party. It’s a pretty common situation to find oneself in.
Yup. I've even found myself in situations where the owner of the third-party service is another team or department within the organization I'm working for or partnering with. Oftentimes, the product/project people on our team tries to make it a business issue with the partner only to find that they don't have the leverage to effect a fix, they get told that the service doesn't offer the SLA you require, or you hear back from the team some hilarious quote like six weeks of development that can't begin until the next quarter. Meanwhile, your feature or product has to launch by the end of the current sprint or quarter.
What happens when the unstoppable force meets the immovable object? The unstoppable force works over the weekend to implement a store-and-forward solution.
FWIW I’ve basically been given basically this exact requirement by a partner with a crappy API.
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.)
So in the end it had to be funneled to a single server keeping a list of requests to make serially to their API?
That's the easy way to do it, the fun one is implementing a distributed lock/queue.
Not actually that hard with a redis lock or any database (Postgres has a specific lock for this but you could also just use a record in a table)
Far easier than the original single threaded solution - and has fault tolerance baked in cause you can run it on multiple clients
> Not actually that hard with a redis lock or any database (Postgres has a specific lock for this but you could also just use a record in a table)
Redis is just another SPOF, and so is Postgres without fiddly third party extensions (that are pretty unreliable in practice, IME). I'm talking about something truly distributed.
What, you need something truly "internet-scale" to make sure your thousands of clients can hit, sequentially, that one faulty api? Would you really be concerned more about Redis failure rates, than said API's failure rates?
If you get into that situation then it's probably because that API is critical and irreplaceable (otherwise you wouldn't be tolerating its problems), so you really don't want to get stuck and be unable to query it. And if you can tolerate a SPOF then there's no reason to bring Redis/Postgres into the picture, you might as well just have a single server doing it.
Plus it's just good practice that I'd want to be following anyway. Once you get in the habit of doing it it doesn't really cost much to design the dataflow right up-front, and it can save you from getting trapped down the line when it's much harder to fix things. Especially for an interview-type situation, why not design it right?
Does a truly distributed solution have no additional cost at all?
To be honest, for me, in an interview-type situation, if you insist that Redis is the problem in that scenario - you would have failed the interview (the interview is never one-way, interviewers can fail it too).
> Does a truly distributed solution have no additional cost at all?
If you literally just drop in etcd or Zookeeper rather than Redis and then develop in the same way then I'd say there's no additional cost to doing that. (I mean sure if you dig hard enough you can always find a way in which solution A is worse than solution B - e.g. most things have worse latency than Redis - but in this scenario the latency of the external API is going to make that irrelevant). Of course if you're just running those in single-node mode and developing against them without thinking about the distributed issues then you've still got plenty of ways to shoot yourself in the foot, but it's a small step in the right direction.
Developing more fully distributed from day 1 requires discipline that takes time to learn, but I'm not convinced that it's actually slower - I'd compare it to e.g. using a strongly typed language, where initially you spend a lot of time bouncing off the guardrails, but over time you adapt yourself and can be productive very rapidly on new projects.
> To be honest, for me, in an interview-type situation, if you insist that Redis is the problem in that scenario - you would have failed the interview (the interview is never one-way, interviewers can fail it too).
Interesting - to me Redis in a system design is very often a case of over-architecting. It's easy to use and programmers enjoy working with it, but very often it isn't letting you do anything you couldn't do without it, and while it can speed things up, I see a lot of cases where the thing it speeds up is something that was already fast enough.
TBH I didn't communicate that clearly - my point was not "Redis in particular", but "whatever you already have at hand, for this usecase". Could also be Postgres or another SQL server.
1 etcd pod doesn't give you "no SPOF", you need 3, and then you need them on multiple VMs (or physical machines if you're not on the cloud/not in k8s), and then the cluster needs to be multi-AZ, and if you're really serious about the "no spof" that may mean geo-redundancy too... come on, just the deployment costs alone are significant.
> my point was not "Redis in particular", but "whatever you already have at hand, for this usecase". Could also be Postgres or another SQL server.
But if you're in the habit of using HA-capable systems then whatever you have to hand will be HA-capable, and so there won't really be any additional cost to using that.
And again, I think there's a real antipattern where people take a single-server application and then claim they've made it fault tolerant by making it run on multiple hosts, but it's still relying on a single DB server. In my experience that doesn't actually improve reliability any (at least not if you've got a good deployment process for your single-server application) and it complicates your architecture to no real benefit. (Indeed, frankly, I think a lot of developers reach for an external database because they have no other idea how to store data from their application, when using embedded sqlite/hbase or - shudder! - the local filesystem, would let them use much simpler architecture and not really reduce the actual reliability of the system).
> 1 etcd pod doesn't give you "no SPOF"
No, but it gives you a clear path to removing your SPOF when the need arises. Which is much harder if you've built your system on Redis.
Or zookeeper for that matter.
A server that has a spike of load and can't cope with it is pretty normal, hard to characterize as "broken".
When the client(s) can send more work than the server can handle there are three options:
Interview question/solution does 2 in a poor way (just adding a pause), it's part of the client and does 3 in the client, when usually this is done in an intermediate component (RMQ/Kafka/Redis/Db/whatever).I implemented an incredibly similar async queue logic for a CLI tool with the option to build sequences of commands
Because it was written in ALGOL 60, none of the mainframe devs are willing to touch that code, and the dozen other clients probably depend on the broken functionality.
That makes it even better, the candidate should ask clarifying questions. I've worked with people who, when encountering some amount of ambiguity, either throw their hands up, or make some random assumptions. Ability to communicate effectively to bridge the gaps in understanding is what I'd expect from any candidate, especially more senior ones.
But that doesn’t work. One could ask why server can handle only one request? Why can’t we upgrade (vertically or horizontally) the server? Why the logic needs to live in the client? And a large etc.
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!”
> One could ask why server can handle only one request?
I've tried that approach in a couple of interviews and, no surprise, I did not get those jobs because interviewers really seem to hate it if you dare step outside the little cocoon of leet they've constructed.
Those are bad questions. The task is given, you're asking why do I have these constraints - obviously you have them because they made them. Without the constraints there's no task.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.
On the contrary, these are great questions to raise at the start and I'd absolutely rate a candidate better for asking them. Too many of my coworkers solve the wrong problem. They treat the symptoms instead of finding the root cause, and so we end up with a fragile patchwork of dirty hacks that get cargo-culted into other code bases.
That being said, the time spent on these questions should be minimal. It should go something like:
Sure, that's completely reasonable. But getting hung up on them for an hour is ridiculous.
I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
Sure, but this isn't a back&forth interview - it's a blog post. The author could have included a section with clarifying questions they expect the candidate to ask, and responses to those questions.
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.
adding the delay is where it throws me off.
what is the delay actually doing? does it actually introduce bugs into that backend? how do we check that?
Absolutely. And it isn’t just about JS, it is about the JS style thinking.
Yeah, I really don’t see how this is a sensible interview question. It does not even mention async await syntax. Expecting knowledge on callbacks seems dated.
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.
Same here. I thought that this specific problem is not that uncommon. On top of my mind: say if the endpoint you're hitting is rate-limited. It doesn't even have to be an API call. I think I've probably written something with the same pattern once or twice before.
I do agree that this is quite javascript specific though.
If it’s rate limited it’s handling the concurrency for you. Just back off from the rate limit.
I feel similarly and again.
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.
I could write a solution to this pretty quickly, I’m very comfortable with callbacks in JavaScript and I’ve had to implement debouncing before. But this interviewer would then disqualify me for not using AI to write it for me. So I don’t understand what the interviewer is looking for.
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?
If you don't care about the order of requests then you can just set up a flag to denote if a task is running, and keep rescheduling the other tasks. Something like
should do the trick. You can test it with BTW, for 4 scheduled tasks, it basically always keeps the order, and I am not sure why. Even if the first task always runs first, the rest 3 should race each other. 5 simultaneously scheduled tasks ruins the order.Nesting at 5 deep increases the timeouts to 4ms! TIL
https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
I tried this at work but ran into issues where if the server had some error or issue or took longer than expected, the job queue grew too large and caused OOM issues. I had to turn it into a manual list in order to debug the problem, though.
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.
Honestly that’s not even an abuse of the event loop / Promises. Making a queue like this is literally one of the intended uses of Promises.
I expected this to be the answer. I guess the interview is not necessarily for JavaScript programmers, but this seems like the correct solution. It brings in some facilities for dealing with errors, too.
This is not the worst interview question I have seen, but it sure could use some improvement.
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 think also trying to work around a faulty server with client code is a bit weird, I could see it happening in practice but my first instinct given this interview would be to insist the server should receive some attention first, or if it is impossible at least this queue should be implemented by another process or machine near the server side.
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.
echoing the other comments about this being a rather terrible interview question...
> 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 dunno about you, but I spend a good amount of time writing my way around buggy servers that I can't change. It seems pretty realistic to me.
I think we all have but that doesn't change that this is almost exclusively a js specific interview question with a very js'y solution to the point of hammering in a imagined "js land" api.
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.
The proper implementation looks kinda bulky to me. Are you not allowed to use promises? Feels more like a naive solution for anyone who has few months of experience with javascript or is it cheating?
You'll need to flatten the promise periodically if you use this approach, otherwise your performance will degrade a bit each time you enqueue something.
I believe you that this works, but I can’t easily read or comprehend it without considerable effort, so I’d grade it below a solution I could.
> without considerable effort
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.
If this is given in Javascript, I'd rate the promise solution higher since a Javascript job involves a ton of promisified async code like this. If this is given in C or pseudo-code, then for sure a good ol stack+flag+loop is looking good enough.
And then once The Anyone gets few more years of experience they revert back to the bulky one.
Dunno, every queue in every major library/project I saw is implemented like this. This is quite readable if you're familiar with js promises.
I actually tried to use this pattern to make an audio controller interface much nicer. If you get a long enough queue, you'll start to run into errors (I'm forgetting the exact message, but it was similar to a maximum recursion depth)
This most likely happened because you had a queue operation which started another queue operation so a recursion was created which consumed every bit of memory it had available.
Readability over brevity for maintainable code (I know an interview doesn't require this, but I look for it)
While this works, it's not exactly intuitive.
In context of JS this kind of promisified async code is intuitive and this pattern is quite common in various projects and libraries, but the solution in C-like pseudocode of course looks more readable for general programming public.
I agree, this seems incredibly readable to me, though I work in TypeScript / JavaScript all day and know the language and its patterns very well.
Neat! and minimum delay can be done with Promise.race
This interview starts off with the interviewer saying it's going to be in JavaScript, and then introducing a piece of code that's clearly not JavaScript:
Doesn't inspire confidence in the interviewer's level of preparation.As long as the candidate feels confused and the interviewer feels brilliant then all is well in the world.
Eh, the implementation is all Javascript and can be approached in any language. They're just providing function signatures with types so the candidate knows what they're working with.
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.
> or any other language (even just pseudo-code)
Here’s an idea for fair interviews:
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!
Might be a whoosh, but really don’t understand the idea of seeing the interviewer as an adversary. Stress in interviews comes from many places but honestly one of the roles of the interviewer is to bring it down.
I think maybe the problem being alluded to is that a lot of interviewers aren't that good at this and instead give off vibes that play up the "I'm judging you from a default presumption that I'm more competent than you" angle.
(Really, it shouldn't be surprising that most technical interviewers aren't that competent, since they usually aren't selected for it.)
Oh god. I’ve met some seriously incompetent people when interviewing - to the point where I’m glad they are the one conducting the interview cause I never want to work with them. I’ve actually finished an interview where I was the candidate with “thank you, but I don’t think this is going to work out”.
To be clear, my point is more that lots of people who are competent at their core jobs and would be perfectly fine coworkers suck at interviewing (but are pressed into service doing it anyway).
Why would anyone agree to participate in interviews then? Do we then force developers to conduct interviews? If so, which ones? The superstars or the ones on PIP? You can see where this is going..
I guess think of it as a promotion/relegation league system, except you get relegated to the "unemployeed" league.
> if the candidate submits a “better” answer than the interviewer’s , candidate takes over their job
Corporate life meets the squid games (I quite like it:)
> 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
with no other push() anywhere else. So how would the queue ever get nonempty in the first place?I have worked in software development for over 35 years. In that time I have found that the most proficient teams are based on having smart people working in teams that get along well. We’d probably call that emotional safety today, but previously, we just said that everyone worked well together. I don’t know what jobs require interviewing for such a specific response, maybe I’ve never needed that skill set on my team. Intelligent, small ego, team players have been the best teams I have worked with, and I’ll continue to hire based on my gut for those individuals.
Oh I see what you're doing here...this is just an interview to massage the interviewer's ego.
It must be so boring working you
How does this interview question massage the interviewer's ego?
> "This is a good way to test how "AI-native" the candidate is."
yuck
In a world of AI-natives, be an AI-drunken-British-football-fan-tourist.
yuck.
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.)
> 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?
Another thing is that the article emphasized that it's single threaded. That by itself guarantees that there will only ever be 1 inflight request, since calling the send() function will block until the request completes, and the callback is called.
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.
JS has an event loop, it's single threaded but still lets you write asynchronous code.
let send = (payload, callback) => fetch(...).then(callback)
fetch() returns a promise synchronously, but it's not awaited.
I'm well aware, but the send() function in the article is not marked as async, and has no .then() calls.
it is too abstract to say for sure, but send might just block until the request is handled off to the next layer (for example succesfully written to the OS network socket buffer), so unless the server carefully closes its recv window until it is done handling the request[1] , no, I wouldn't expect send to block until the server is done handling the request.
[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.
Yeah that confused me at first too. They seem to be treating send() as if it has the same behavior as a setTimeout() call. If you think of it that way, it starts to make sense.
You're absolutely right - the naive implementation has a logical flaw where the queue would always remain empty since tasks are only added when the queue is non-empty, creating a catch-22 situation where the queue can never grow.
That's how I read it too. Nothing is ever added.
That's correct.
If I were interviewed by someone presenting me with this task, I would spend a bit of time helping the interviewer clean up the problem and try to get to where they can explain what they want with just words. Clearly.
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.
He gave you a function, its signature, and its context in the codebase. I don't really know what you are looking for to make it clearer.
I've conducted a fair number of interviews. At least one of the problems I pose to candidates are to test if they will ask questions that clarifies what I am asking for. Because being able to articulate both what you want to accomplish and what the non-negotiable constraints are, is a key skill. The more senior you are, the higher this part of the interview gets weighted.
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.
> 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.
I am kind of shocked you have never had to do this, or that you think it is unreasonable to ask. Sure, it is totally reasonable to ask questions about whether this is standard practice, especially in the real world. But an interview is an environment where you are given the constraints and obviously there isn't time to explain every detail about why something is the way it is.
Yeah, we do want the server to be fixed–there is a team working on it, and they'll have it ready next week. But we need something to work now. That's the where the interview places you. If you are going to be the person who values purity instead of just doing the job when the constraints actually call for it, are you really selling yourself as a good candidate?
Turn the argument on its head: why is it reasonable to ask someone who presumably knows better to waste time trying to solve a server problem on the client side? And why would it be unreasonable for a candidate to reject the premise and suggest a better solution?
(I often pose problems to candidates where challenging the given premise IS the point. You want people who will speak up)
I've spent perhaps a couple of decades designing and implementing various forms of distributed systems, and there are good reasons to avoid trying to hack your way out of trouble by requiring clients to behave a certain way. You will always have less control, it is almost never any easier than fixing the server side, and it doesn't actually address the root problem. You start at the end where the problem is instead of introducing hacks that run the risk of becoming long-lived.
You can always put something in front of a misbehaving backend that can compensate for the problem on the server side. In fact, this common enough that there exists a rich fauna of components that are used to address these kinds of issues. From more generic load balancers to more advanced application specific middleware. I've worked on perhaps half a dozen such systems and I've designed and implemented two of them from the ground up.
So yes, when people start trying to solve server problems by hacking the client, I tend to assume that they probably don't know what they are doing. And if they're not open to the possibility that they are wrong, why on earth would I waste my time working for them? Let alone try to convince them? Life is too short.
You do understand that this is a one-hour interview, not an extended discussion about your software's architecture, right? Are you going to also call out the fact that this doesn't support a hundred million concurrent users and multi-region failover either?
>> If I were interviewed by someone presenting me with this task, I would spend a bit of time helping the interviewer clean up the problem and try to get to where they can explain what they want with just words. Clearly
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.
> The interviewer would fail you because this interviewer > wants to feel superior and more powerful
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.
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.
the async part isnt very exciting, but its the callback after the entry has been through the queue and worked on.
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've implemented multiple production versions of this problem (but not in JavaScript)[1], so maybe my view of this problem is miscalibrated...
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...
You explained how it is too easy, so how is it also too hard?
It's too hard because the variations you could add to it (multi threading) that add enough depth to make it hard make it too hard, in my opinion. If you look at the implementation I linked in my previous comment, it's fully lock-free, which is pretty unreasonable to expect from anyone who isn't already familiar with lock free concurrency. On the other hand the version with a lock is basically identical to the single thread version. Asking for the two-lock queue is also a bad interview question because it's not something you'd reasonably expect someone to derive in an interview.
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.
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
I've seen somewhat similar things in embedded development, e.g. ADCs with a triggered conversion mode that start a new conversion on receipt of a new trigger, abandoning a previous conversion if one was in progress. They fire an interrupt when the conversion completes. Not in any way buggy or unexpected, ICs generally either can block or can immediately respond but can't queue multiple requests.
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.
After some years applying for different positions, I started asking receuiters about their hiring process and straight out dropping out when there were technical tests like this.
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.
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.
> (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.
I did this in the firmware of a VoIP base station.
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.
How did you make it wait free with only compare and swap?
Why is the method called sendOnce? It’s send with a capacity limiter / semaphore right, so what about it is Once?
I think it really ought to be called "sendOneAtATime" but I assume the author just picked a bad name for it.
I'm really confused because I had to scroll half the comment section for the word `semaphore`.
This seems to be an interview question about JS esoterica, not concurrent programming.
Well, I had an interview recently where I passed with flying honors the technical interview but they failed me at "cultural fit", which was strangely, the last one in the series.
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.
I would respectfully suggest that this entire approach creates a pathological distributed system, where the client is trying to internally keep track of the state of a server, but without any of the supervision tools would need to do so reliably. (And, as a bonus, it's doing this with a callback hell) What happens if either one restarts/crashes? What happens if you accidentally launch 2 clients?
It’s funny because I have had ti implement “serialized fetch()” a few times recently, with delays and random jitter too.
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 don't understand what's tricky about converting callback-style to promise-style. Even writing a decorator is trivial.
It’s not tricky if you understand how both work. If you don’t it will be a challenge, especially if you add all the correct error handling and cancelation. Bonus points if you make it work with only up to N tasks running at a time.
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.
You can also schedule code to run each "tick" of the event loop, which is a non-blocking version of a while loop.
Or you could promisify the send function and use normal async/await.
Or you could actually spin up a new worker thread and get multithreading :PDefinitely one of those where the interviewer wants to show how smart they are.
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 intro isnt throttling, its request serialization. there isnt some limit to keep your requests to, just that its one at a time. it could go as fast or as slow as the individual requests finish.
its still not a great architecture, but its different from throttling
> But that server is faulty!! If it has to handle multiple requests at once, it starts to break down. 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
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.
This is handled in the framing of the question:
“… 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.
The whole point of this interview is that the candidate is operating on a single-threaded environment.
These are multiple assumptions "This queue is only on one machine and on one thread", what's the real world use-case here? Not saying there's none but make it clear. I wouldn't want to work for a company that has to think of some random precise question instead of e.g. "when would you not use mysql?"
I guess I don’t want to hire candidates who assume the world is single-threaded
Posting interview questions on Hacker News is so funny. Regardless of what the question is half the people will tell you that it's an interviewer ego trip that has no relevance to the real world while the other half will explain how interviews are actually a total waste of time and how carpenters do it right (obviously, without actually consulting how carpenters do their interviews). If the question has anything in it that's not an array then it's called "Leetcode" and clearly FAANG-engineer biased. If it has any other form then it's too confusing and too contrived. Of course, the end result of this discussion is that the author is a horrible employee at a horrible workplace and nobody should ever want to work with them. Thank god that 'randomuser123 was able to figure out that they were telling on themselves and explaining that if they were in this interview they'd stand up and tell the interviewer how their entire architecture was wrong and they should be ashamed for even asking the question instead of changing the world around them. And then everyone claps.
Phenomenal comment, thank you for writing it, made my day :)
Promises in JS make this stuff much easier (at least to my mind):
const lockify = f => {
Easier to write. But there is a case to be made that code which can be understood without understanding somewhat esoteric language internals is superior.
I guess "esoteric" is in the eye of the beholder, but Promises seem a lot easier than the old callback style we used to use for asynchronous operations.
Is code wrote for a broken server.
It makes no sense even with common js idiom.
Ok, but that's not relevant to my point.
Plus, in real life you do need to interact with broken servers – that doesn't mean you should make your code less readable as well.
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"
I made use of this in my LisaGUI project; I referenced an absolutely fantastic example on this on SO: https://stackoverflow.com/a/63208885
As a general comment, I wish hiring managers found some other outlets for their enormous ego and insecurities than the process of hiring of software engineers.
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
> 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.
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.
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.
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.
In the interview, am I allowed to fix the server (which apparently "breaks down handling concurrent requests") instead of working on this silly programming exercise?
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")
> 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.
One of the best interview questions I ever received, I was asked to explain how something I liked worked in detail. Could be literally anything, just break it down step by step. I was told I could use the whiteboard but didn't have to.
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.
Heh heh. I dont understand what the fuss is about, AsyncQueue is kinda cool in JS. I use it, from time to time, to implement async generators that can be iterated over with for await.
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.
While I'm at it, here's my version, if people want to see and give feedback:
Their "proper implementation" lacks sufficient error/exception handling around the callback() call. It'll become permanently broken if it throws anything.
“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.
The use-case described is ill suited to be addressed by the client.
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.
Yeah I think the premise is a bit poorly designed, I would just wave it away and focus on the queue. The coding problem itself is pretty well defined. And I think the premise is intentionally presented kind of poorly defined, which makes me think it's meant to not really be part of the problem.
This is addressed in the article.
> 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).
This might be a server interacting with another server.
I'd just have them play Factorio and watch how they reason.
Uh oh, I am horrible at Factorio ＼(〇_ｏ)／ But I am a mathematician, I wonder if that makes things better or worse... (•ิ_•ิ)?
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.
I spend more time than my interviewees on the question to try to solve the problem every way that it is possible to solve it. If a candidate picks any of the solutions they pass. If they pick a solution I didn't know of they also pass (with flying colors) but I fail.
So do you want to give candidates infinite time (which they won't have on-the-job) or not attempt to assess their coding ability or what?
Is the send function considered non-blocking?
Why would it have a completion callback if it wasn't?
"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.
Talk about javascript, present code in typescript. This would put me (the interviewee) off
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.
This is a complete nonsense. OP has invented a tricky technical test for themselves which they have spent long amounts of time thinking about.
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.
It's a great question if you want a Node.js developer. But what if they come from a Go or Java background.
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.
[dead]
[dead]