4 ms·

The problem is usually solved in tandem with myself or another full-time engineer. We offer hints and use it to watch the candidates thinking. The best candidat

The problem is usually solved in tandem with myself or another full-time engineer. We offer hints and use it to watch the candidates thinking. The best candidates usually surprise us with their solution. Do we use it as a filter? Only to the extent that it filters out candidates who don't want to put in the work, or who can't actually code.

gafferongames 3y ago
Perhaps it also filters out candidates who want to rewrite everything in rust.
- cryptonector 3y ago
  That's pretty funny. ISTM that now that you have HN commentary you're thinking a bit more expressly about what you're really trying to achieve with this interview question.
  - gafferongames 3y ago
    To be clear, this is actually a historical interview question that we've used successfully in the past. We're no longer hiring for this specific role, but I figured writing a blog post to share the solution to help people who for one reason or another, find themselves needing to implement a highly scalable UDP backend, they would now hit this article and at least have some pointers about SO_REUSEPORT and so on as well as increasing socket send and receive buffer sizes, ulimits and so on. btw. This question actually comes out of a core part of the Network Next backend, which was problematic for us and a thorn in our ass in various ways over a period of 5 years. It took us an extremely long time as engineers not familiar with everything needed to solve this question, to correctly solve it and scale up past 25M+ clients. As such it feels like information worth sharing, after all is said and done.
    - cryptonector 3y ago
      > It took us an extremely long time as engineers not familiar with everything needed to solve this question, to correctly solve it and scale up past 25M+ clients. But you want a senior applicant to solve it in a weekend. What you'll get is people who are already somewhat familiar with these issues to apply. Chances are such people are indeed senior and can think their way out of a paper bag. In fact, you'll get very valuable people if you get them at all. I hope you understand just how valuable.
      - gafferongames 3y ago
        You seem really hung up on this as an interview question. I repeat that it's a historical question that has been really successful for us, and we scale it up and down according to the experience level of the candidate. This is honestly a toy problem for people with the direct experience that we are looking for, and there are a bunch of levels of implementation according to the level of the candidate that result in a pass. We've used this successfully to hire candidates who don't even know golang, and to filter out engineers who bluster and just wave hands and say "this is easy just XYZ...". OK cool, show me. Like all good interview questions it has an infinite number of solutions and it's primarily used to determine if the candidate is "smart and gets things done" AND as a test to filter out candidates who talk the talk but can't walk the walk. YMMV. It's being shared now primarily to help people who for some reason or another need to code backends in UDP, once the solution is published, at least there will be something that pops up in the google search results and gives them some hints. Jesus. Next time I won't even bother trying to help people :)
        cryptonector 3y ago
        The reaction you're getting is that the question seemed abusive. I also had that sense, but I was also very curious about your question, so we explored it, perhaps not unlike how we might have in an actual interview. Interviews are two-way streets. It seems to me that you're a bit defensive about your interview question! Now what? :) Mind you, I do like this sort of interview question as a question not so much as a fetch-a-rock exercise. The thing is that when you ask this sort of question you can very easily explore the candidate's ability to explore the solution space and show off what they know, but there's an end time, while with a task it can easily become a time sink, especially if the candidate chooses to go above and beyond and... fail to make the cut because in that time you picked a different candidate.

gafferongames 3y ago

Perhaps it also filters out candidates who want to rewrite everything in rust.

cryptonector 3y ago
That's pretty funny. ISTM that now that you have HN commentary you're thinking a bit more expressly about what you're really trying to achieve with this interview question.
- gafferongames 3y ago
  To be clear, this is actually a historical interview question that we've used successfully in the past. We're no longer hiring for this specific role, but I figured writing a blog post to share the solution to help people who for one reason or another, find themselves needing to implement a highly scalable UDP backend, they would now hit this article and at least have some pointers about SO_REUSEPORT and so on as well as increasing socket send and receive buffer sizes, ulimits and so on. btw. This question actually comes out of a core part of the Network Next backend, which was problematic for us and a thorn in our ass in various ways over a period of 5 years. It took us an extremely long time as engineers not familiar with everything needed to solve this question, to correctly solve it and scale up past 25M+ clients. As such it feels like information worth sharing, after all is said and done.
  - cryptonector 3y ago
    > It took us an extremely long time as engineers not familiar with everything needed to solve this question, to correctly solve it and scale up past 25M+ clients. But you want a senior applicant to solve it in a weekend. What you'll get is people who are already somewhat familiar with these issues to apply. Chances are such people are indeed senior and can think their way out of a paper bag. In fact, you'll get very valuable people if you get them at all. I hope you understand just how valuable.
    - gafferongames 3y ago
      You seem really hung up on this as an interview question. I repeat that it's a historical question that has been really successful for us, and we scale it up and down according to the experience level of the candidate. This is honestly a toy problem for people with the direct experience that we are looking for, and there are a bunch of levels of implementation according to the level of the candidate that result in a pass. We've used this successfully to hire candidates who don't even know golang, and to filter out engineers who bluster and just wave hands and say "this is easy just XYZ...". OK cool, show me. Like all good interview questions it has an infinite number of solutions and it's primarily used to determine if the candidate is "smart and gets things done" AND as a test to filter out candidates who talk the talk but can't walk the walk. YMMV. It's being shared now primarily to help people who for some reason or another need to code backends in UDP, once the solution is published, at least there will be something that pops up in the google search results and gives them some hints. Jesus. Next time I won't even bother trying to help people :)
      - cryptonector 3y ago
        The reaction you're getting is that the question seemed abusive. I also had that sense, but I was also very curious about your question, so we explored it, perhaps not unlike how we might have in an actual interview. Interviews are two-way streets. It seems to me that you're a bit defensive about your interview question! Now what? :) Mind you, I do like this sort of interview question as a question not so much as a fetch-a-rock exercise. The thing is that when you ask this sort of question you can very easily explore the candidate's ability to explore the solution space and show off what they know, but there's an end time, while with a task it can easily become a time sink, especially if the candidate chooses to go above and beyond and... fail to make the cut because in that time you picked a different candidate.