6 ms·

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

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 1y ago
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 1y ago
> 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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
  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!”
  - deleted 1y ago
    [deleted]
  - zimpenfish 1y ago
    > 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.
  - deleted 1y ago
    [deleted]
  - sfn42 1y ago
    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 1y ago
The confusing part for me is why I’m dicking around with the client when the server’s broken.
- MontyCarloHall 1y ago
  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 1y ago
    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 1y ago
    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.
    - deleted 1y ago
      [deleted]
- mikeocool 1y ago
  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.)
  - 1y ago
trhway 1y ago
Absolutely. And it isn’t just about JS, it is about the JS style thinking.

qu0b 1y ago

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 1y ago

> 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 1y ago

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 1y ago
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 1y ago
  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 1y ago
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!”
- deleted 1y ago
  [deleted]
- zimpenfish 1y ago
  > 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.
- deleted 1y ago
  [deleted]
- sfn42 1y ago
  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 1y ago

The confusing part for me is why I’m dicking around with the client when the server’s broken.

MontyCarloHall 1y ago
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 1y ago
  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 1y ago
  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.
  - deleted 1y ago
    [deleted]
mikeocool 1y ago
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.)
- 1y ago

trhway 1y ago

Absolutely. And it isn’t just about JS, it is about the JS style thinking.