[HN Gopher] Async Queue - One of my favorite programming intervi...
___________________________________________________________________
Async Queue - One of my favorite programming interview questions
Author : davidgomes
Score : 227 points
Date : 2025-07-06 16:46 UTC (1 days ago)
(HTM) web link (davidgomes.com)
(TXT) w3m dump (davidgomes.com)
| dudeinjapan wrote:
| 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.
| davidgomes wrote:
| The whole point of this interview is that the candidate is
| operating on a single-threaded environment.
| ramon156 wrote:
| 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?"
| dudeinjapan wrote:
| I guess I don't want to hire candidates who assume the world
| is single-threaded
| jonchurch_ wrote:
| 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.
| reillyse wrote:
| 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.
| qu0b wrote:
| 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.
| numbsafari wrote:
| > 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.
| isbvhodnvemrwvn wrote:
| 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.
| mgfist wrote:
| 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.
| 8note wrote:
| 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?
| dakiol wrote:
| 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!"
| zimpenfish wrote:
| > 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.
| sfn42 wrote:
| 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.
| gopher_space wrote:
| The confusing part for me is why I'm dicking around with the
| client when the server's broken.
| MontyCarloHall wrote:
| 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?"
| efitz wrote:
| 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.
| diesal11 wrote:
| 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.
| mikeocool wrote:
| 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.)
| balder1991 wrote:
| So in the end it had to be funneled to a single server
| keeping a list of requests to make serially to their API?
| lmm wrote:
| That's the easy way to do it, the fun one is implementing
| a distributed lock/queue.
| reillyse wrote:
| 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
| lmm wrote:
| > 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.
| virgilp wrote:
| 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?
| lmm wrote:
| 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?
| DmitryOlshansky wrote:
| Or zookeeper for that matter.
| rustyminnow wrote:
| 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.
| Jarwain wrote:
| 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.
| xnorswap wrote:
| 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.
| Jarwain wrote:
| 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.
| Xss3 wrote:
| I implemented an incredibly similar async queue logic for a
| CLI tool with the option to build sequences of commands
| layer8 wrote:
| 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.
| mechanicalpulse wrote:
| 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.
| lazyant wrote:
| 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).
| trhway wrote:
| Absolutely. And it isn't just about JS, it is about the JS
| style thinking.
| ZiiS wrote:
| 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.
| armitron wrote:
| 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.
| jonchurch_ wrote:
| 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.
| aidos wrote:
| 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.
| michaelsalim wrote:
| 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.
| reillyse wrote:
| If it's rate limited it's handling the concurrency for you.
| Just back off from the rate limit.
| MatthiasPortzel wrote:
| 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.
| ncann wrote:
| > 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?
| JohnKemeny wrote:
| That's how I read it too. Nothing is ever added.
| Arch-TK wrote:
| That's correct.
| 63stack wrote:
| 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.
| _benton wrote:
| 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.
| 63stack wrote:
| I'm well aware, but the send() function in the article is
| not marked as async, and has no .then() calls.
| gpderetta wrote:
| 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.
| rehevkor5 wrote:
| 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.
| ethan_smith wrote:
| 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.
| bluelightning2k wrote:
| 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.)
| jnettome wrote:
| 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.
| comrade1234 wrote:
| 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.
| 4ndrewl wrote:
| Definitely one of those where the interviewer wants to show how
| smart they are.
| IdontKnowRust wrote:
| 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
| fastball wrote:
| How does this interview question massage the interviewer's ego?
| thedude14 wrote:
| 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.
| lubujackson wrote:
| 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.
| GeoAtreides wrote:
| > 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
| dawnerd wrote:
| 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.
| skydhash wrote:
| 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)?
| GeoAtreides wrote:
| I did it in a couple of hours, it's not a difficult problem
| (but, to be fair, I'm a senior dev)
| lordnacho wrote:
| 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.
| nothrabannosir wrote:
| 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?
| odo1242 wrote:
| 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.
| bmacho wrote:
| 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.
| jonchurch_ wrote:
| Nesting at 5 deep increases the timeouts to 4ms! TIL
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Window/setT...
| remram wrote:
| 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.
| Jarwain wrote:
| 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.
| brettgriffin wrote:
| 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.
| brunooliv wrote:
| Agreed, this is just terrible for the field as a whole it's
| like we're regressing or something
| joquarky wrote:
| 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.
| esafak wrote:
| 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.
| ThrowawayR2 wrote:
| 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.
| tkiolp4 wrote:
| 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.
| Manuel_D wrote:
| 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.
| thedevilslawyer wrote:
| How's failing medicine not depressing!
| bryanrasmussen wrote:
| 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.
| thedevilslawyer wrote:
| That's like, your opinion. Any argument you can make for
| leetcode, one can make on the medical certification exam
| as well.
| glitchc wrote:
| Perhaps the bar should be as high as law and medicine if we
| want people to take our industry just as seriously.
| FpUser wrote:
| 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.
| joquarky wrote:
| Just make sure to save up before ageism kicks in.
| throw234234234 wrote:
| 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.
| FpUser wrote:
| >"software for controlling some life support system..."
|
| I believe there are processes to ensure this kind of
| software is safe (obviously to a degree).
| SketchySeaBeast wrote:
| 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.
| FpUser wrote:
| I develop software for various areas. The ones that come
| anywhere close to regulated areas surely gets audited.
| no_wizard wrote:
| 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
| kfajdsl wrote:
| What would be on such an exam? Pseudocode, logic puzzles?
|
| Certainly not specifics on any particular technology,
| right?
| no_wizard wrote:
| 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
| FpUser wrote:
| >"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
| no_wizard wrote:
| 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.
| zaphirplane wrote:
| 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
| osigurdson wrote:
| 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.
| haiku2077 wrote:
| > 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.
| osigurdson wrote:
| 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.
| no_wizard wrote:
| 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.
| atraac wrote:
| For the same reason we have 2137 libraries, frameworks and
| languages that do the same thing - because everyone thinks
| they can do it better.
| no_wizard wrote:
| 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
| chis wrote:
| 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.
| trhway wrote:
| 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.
| lmm wrote:
| > 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.
| coherentpony wrote:
| > 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.
| hobs wrote:
| 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.
| coherentpony wrote:
| 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.
| hobs wrote:
| Its very specialized, since I was hiring for data roles I
| used hex.tech with some examples and it was great.
| kmac_ wrote:
| 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.
| 000ooo000 wrote:
| 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?
| throwaway2037 wrote:
| 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.
| rjst01 wrote:
| 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.
| akoboldfrying wrote:
| In my experience the signal is pretty strong.
| rjst01 wrote:
| Are you able to share how you evaluated this? Is this
| based on gut-feeling or is it data-driven?
| akoboldfrying wrote:
| Gut feeling based on the generally very high competence
| of my colleagues when I was at Google.
| infecto wrote:
| 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.
| osigurdson wrote:
| >> 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.
| georgemcbay wrote:
| > 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.
| 4ndrewl wrote:
| It's always
|
| - someone else's money (zirp, middle-eastern sugar
| daddies, juicy government contracts)
|
| - adverts
| no_wizard wrote:
| 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
| collingreen wrote:
| 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.
| akoboldfrying wrote:
| "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?
| no_wizard wrote:
| define "tricky problem". Given the nature of something
| being tricky, it could well be too heavily reliant on the
| 'trick'.
| akoboldfrying wrote:
| 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.)
| hobs wrote:
| 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.
| jen20 wrote:
| > 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.
| Twirrim wrote:
| 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.
| swat535 wrote:
| > 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.
| tayo42 wrote:
| 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.
| renegade-otter wrote:
| 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?
| no_wizard wrote:
| I think quant finance is similarly bad
| rrdharan wrote:
| Actually Microsoft started this in the 1990s, long before
| FAANG was a thing. They just all adopted it.
| otterley wrote:
| "Why are manhole covers round?" "How many dry cleaners
| are in the city of Seattle?" were both infamous Microsoft
| interview questions.
| dekhn wrote:
| Previously known as "Fermi questions"- commonly asked of
| undergrads and grad students in quantitative fields.
| georgemcbay wrote:
| > 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.
| shaftway wrote:
| 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.
| throwaway2037 wrote:
| 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.
| no_wizard wrote:
| 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
| anon12512 wrote:
| 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.
| saagarjha wrote:
| 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?
| weego wrote:
| 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.
| higeorge13 wrote:
| 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.
| rockostrich wrote:
| 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.
| Twirrim wrote:
| 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.
| actinium226 wrote:
| 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.
| quietbritishjim wrote:
| > 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?
| morsecodist wrote:
| 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.
| mdavid626 wrote:
| 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.
| DavidWoof wrote:
| 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.
| prats226 wrote:
| 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?
| rubyn00bie wrote:
| 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.
| 8note wrote:
| 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
| dakiol wrote:
| 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.
| fastball wrote:
| 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?
| saagarjha wrote:
| 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.
| dakiol wrote:
| 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!
| billforsternz wrote:
| > 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:)
| glitchc wrote:
| 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..
| tengbretson wrote:
| I guess think of it as a promotion/relegation league system,
| except you get relegated to the "unemployeed" league.
| yoz-y wrote:
| 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.
| ameliaquining wrote:
| 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.)
| reillyse wrote:
| 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".
| ameliaquining wrote:
| 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).
| koakuma-chan wrote:
| 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"
| relativeadv wrote:
| > "This is a good way to test how "AI-native" the candidate is."
|
| yuck
| sbstp wrote:
| yuck.
| ykonstant wrote:
| In a world of AI-natives, be an AI-drunken-British-football-
| fan-tourist.
| ww520 wrote:
| 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.
| 8note wrote:
| 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
| ww520 wrote:
| > 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
| wonnage wrote:
| 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
| evil-olive wrote:
| 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.
| resonious wrote:
| 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.
| rustystump wrote:
| 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.
| didip wrote:
| 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.
| resonious wrote:
| This might be a server interacting with another server.
| fastball wrote:
| 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).
| cdrini wrote:
| 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.
| neallindsay wrote:
| Promises in JS make this stuff much easier (at least to my mind):
|
| const lockify = f => { let lock =
| Promise.resolve() return (...args) => {
| const result = lock.then(() => f(...args)) lock =
| result.catch(() => {}) return result.then(v => v)
| } }
| fastball wrote:
| 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.
| yeasku wrote:
| Is code wrote for a broken server.
|
| It makes no sense even with common js idiom.
| fastball wrote:
| 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.
| neallindsay wrote:
| 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.
| jtchang wrote:
| Is the send function considered non-blocking?
| isbvhodnvemrwvn wrote:
| Why would it have a completion callback if it wasn't?
| _benton wrote:
| 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. let q = Promise.resolve(),
| sendAsync = (p) => new Promise(r => send(p, r)),
| sendOnce = (p, c, ms) => setTimeout(_ => q.then(_ =>
| sendAsync(p)).then(c), ms)
|
| Or you could actually spin up a new worker thread and get
| multithreading :P
| charleslmunger wrote:
| 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...
| fastball wrote:
| You explained how it is too easy, so how is it also too hard?
| charleslmunger wrote:
| 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.
| kazinator wrote:
| 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.
| charleslmunger wrote:
| How did you make it wait free with only compare and swap?
| IgorPartola wrote:
| 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).
| bvrmn wrote:
| I don't understand what's tricky about converting callback-
| style to promise-style. Even writing a decorator is trivial.
| IgorPartola wrote:
| 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.
| nmca wrote:
| Why is the method called sendOnce? It's send with a capacity
| limiter / semaphore right, so what about it is Once?
| saagarjha wrote:
| I think it really ought to be called "sendOneAtATime" but I
| assume the author just picked a bad name for it.
| mgradowski wrote:
| 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.
| ayaros wrote:
| I made use of this in my LisaGUI project; I referenced an
| absolutely fantastic example on this on SO:
| https://stackoverflow.com/a/63208885
| joquarky wrote:
| I'd just have them play Factorio and watch how they reason.
| ykonstant wrote:
| Uh oh, I am horrible at Factorio \(0_o)/ But I am a
| mathematician, I wonder if that makes things better or worse...
| (*i_*i)?
| SAI_Peregrinus wrote:
| 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.
| robertlagrant wrote:
| > (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.
| andrewstuart wrote:
| "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.
| xg15 wrote:
| > _The bug in this implementation is that if sendOnce is called
| consecutively and the previous request hasn 't finished yet, then
| we violate the "one request at a time" requirement._
|
| Maybe I haven't had enough coffee yet, but the "naive"
| implementation looks like it wouldn't use the queue at all,
| regardless how quickly or slowly you fire off the requests.
|
| The code is literally if (requestQueue.length ===
| 0) { ... } else {
| requestQueue.push(...) }
|
| with no other push() anywhere else. So how would the queue ever
| get nonempty in the first place?
| pavlov wrote:
| 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: declare function send<P>(
| payload: P, callback: () => void ): void;
|
| Doesn't inspire confidence in the interviewer's level of
| preparation.
| ipnon wrote:
| As long as the candidate feels confused and the interviewer
| feels brilliant then all is well in the world.
| diesal11 wrote:
| 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.
| saagarjha wrote:
| > or any other language (even just pseudo-code)
| jwmoz wrote:
| 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.
| vrighter wrote:
| Talk about javascript, present code in typescript. This would put
| me (the interviewee) off
| bborud wrote:
| 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.
| saagarjha wrote:
| 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.
| bborud wrote:
| 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.
| andrewstuart wrote:
| >> 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.
| saagarjha wrote:
| 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.
| davidgomes wrote:
| Phenomenal comment, thank you for writing it, made my day :)
| gloosx wrote:
| 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? const PromiseQueue = { queue:
| Promise.resolve(true), sendOnce(request) {
| return new Promise((resolve, reject) => { this.queue
| = this.queue .then(request)
| .then(resolve) .catch(reject) })
| } }
| mohsen1 wrote:
| Neat! and minimum delay can be done with Promise.race
| mind-blight wrote:
| 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)
| gloosx wrote:
| 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.
| damidekronik wrote:
| And then once The Anyone gets few more years of experience they
| revert back to the bulky one.
| gloosx wrote:
| 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.
| MrDarcy wrote:
| 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.
| gloosx wrote:
| 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.
| dbetteridge wrote:
| 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.
| gloosx wrote:
| 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.
| no_wizard wrote:
| 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.
| a-priori wrote:
| 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.
| octo888 wrote:
| 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
| ctvo wrote:
| > 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.
| stevepotter wrote:
| 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.
| kinow wrote:
| 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.)
| quibono wrote:
| > 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?
| FirmwareBurner wrote:
| 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.
| quibono wrote:
| > 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.
| kinow wrote:
| > 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.
| kinow wrote:
| 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.
| FirmwareBurner wrote:
| _> 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
| kinow wrote:
| > 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.
| kinow wrote:
| 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).
| stevepotter wrote:
| 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.
| kinow wrote:
| 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.
| nobleach wrote:
| 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!
| jasonjmcghee wrote:
| 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.
| pak9rabid wrote:
| Coding is like sex, both are susceptible to performance anxiety
| when made to be done in front of others.
| MathMonkeyMan wrote:
| It gets easier with practice.
| heresie-dabord wrote:
| > 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.
| stevepotter wrote:
| 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.
| donatj wrote:
| 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.
| kinow wrote:
| 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.
| MichaelRo wrote:
| 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.
| time0ut wrote:
| 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...
| jwrallie wrote:
| 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.
| tekkk wrote:
| 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.
| tekkk wrote:
| While I'm at it, here's my version, if people want to see and
| give feedback: export interface
| AsyncQueueOptions { timeoutSeconds?: number }
| export class AsyncQueue<T> { private readonly queue:
| Promise<T | undefined>[] = [] readonly timeoutSeconds:
| number private timeout: ReturnType<typeof setTimeout> |
| undefined private reject = () => {} private
| resolve = (value: T | PromiseLike<T>) => {} /**
| * @param timeoutSeconds @default 25 */
| constructor({ timeoutSeconds = 25 }: AsyncQueueOptions = {}) {
| this.timeoutSeconds = timeoutSeconds if
| (timeoutSeconds > 100) { console.warn(`You are
| initializing AsyncQueue with over 100s timeout:
| ${timeoutSeconds}`) } this.queue.push(
| new Promise<T | undefined>((resolve, reject) => {
| this.resolve = resolve this.reject = reject
| this.timeout = setTimeout(() => resolve(undefined),
| timeoutSeconds * 1000) }) ) }
| next(): Promise<T | undefined> | undefined { return
| this.queue.shift() } push(msg: T) {
| this.resolve(msg) this.queue.push( new
| Promise<T | undefined>((resolve, reject) => {
| this.resolve = resolve this.reject = reject
| clearTimeout(this.timeout) this.timeout =
| setTimeout(() => resolve(undefined), this.timeoutSeconds *
| 1000) }) ) }
| close(msg?: T) { if (msg) {
| this.resolve(msg) }
| clearTimeout(this.timeout) } }
| delegate wrote:
| "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.
| dekhn wrote:
| 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")
| 12_throw_away wrote:
| 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?
| rehevkor5 wrote:
| Their "proper implementation" lacks sufficient error/exception
| handling around the callback() call. It'll become permanently
| broken if it throws anything.
| tk90 wrote:
| > 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.
___________________________________________________________________
(page generated 2025-07-07 23:01 UTC)