4 ms·

> While I'm confident that an experienced senior engineer could find a solution over a weekend Over weekend? Either I'm misunderstanding it (are you supposed t

> While I'm confident that an experienced senior engineer could find a solution over a weekend Over weekend? Either I'm misunderstanding it (are you supposed to write your own NAT-pinning solution? TURN?) or this sholudn't take more than couple of hours.

deleted 3y ago
[deleted]
gafferongames 3y ago
Cool. Show me
- dilyevsky 3y ago
  I actually received something similar for take-home challenge years ago so it may not be as "out there" as you think it is =) (at least if you work in telecom/networking space)
  - gafferongames 3y ago
    The specific challenge here is: "You are tasked with creating a client/server application in Golang that runs in Google Cloud. The client in this application must communicate with the server over UDP. Each client sends 100 requests per-second. Each request is 100 bytes long. The server processes each request it receives and forwards it over HTTP to the backend. The backend processes the request, and returns a response containing the FNV1a 64 bit hash of the request data. The server returns the response it receives from the backend down to the client over UDP. Implement the client, server and backend in Golang and Terraform such that it scales to more than 1M clients. Provide estimates of the cost to run the solution each month at a steady load of 1M clients, as well as some options you would recommend as next steps to reduce the cost. IMPORTANT: When you load test this system, make sure you are communicating between the client, server and backend using internal addresses to avoid egress bandwidth charges."
    - dilyevsky 3y ago
      Ok so if NAT punch-through is not needed I guess the only tricky thing is connection pooling on the backend side? I sort of agree with the other poster - that if you had done something like this before it's trivial and if you haven't, it's a bit hard to research on your own.
      - gafferongames 3y ago
        100%. There is a class of programmer for whom this would be a toy problem. There is another class of programmer who may be young or not directly experienced in this space, but who is very intelligent and an excellent problem solver and is willing to work hard. The question was designed to find both types of applicants.
nyrikki 3y ago
As posed, this problem is a toy one and fairly easy. 1) The arrival rate is constant, vs the more realistic Poisson distribution 2) The response fits in a single packet 3) Requests are consistent size. I don't think most companies are going to have the resources to take advantage of QUIC and HTTP/3 for a while. While head of line blocking is theoretically gone, most programming is based around ordered delivery. I see lots of projects doing single streams to minimize complexity, but that severely reduces large asset transfer. I am sure the FAANG crew will gain a lot of advantages, but tooling needs to be there for the rest of us. Obviously some will take advantage of it, but it is a shift in responsibility to the application and dealing with window scaling and out of order delivery is expensive. IMHO, UDP is simply a target because legacy systems would make a new option that was superior difficult if impossible to implement. As I have supported voip and streaming over the public Internet, I admittedly have a jaded view. But I am not looking forward to supporting the quirks of every client when it was easy to hand that off to the OS. Hopefully I am wrong, and SWEs will be good at dealing with ood and random failures and standards will offload the cost of implementing what TCP gave us for free. But I don't think people realize how easy reliable, ordered delivery makes programming.

deleted 3y ago

[deleted]

gafferongames 3y ago

Cool. Show me

dilyevsky 3y ago
I actually received something similar for take-home challenge years ago so it may not be as "out there" as you think it is =) (at least if you work in telecom/networking space)
- gafferongames 3y ago
  The specific challenge here is: "You are tasked with creating a client/server application in Golang that runs in Google Cloud. The client in this application must communicate with the server over UDP. Each client sends 100 requests per-second. Each request is 100 bytes long. The server processes each request it receives and forwards it over HTTP to the backend. The backend processes the request, and returns a response containing the FNV1a 64 bit hash of the request data. The server returns the response it receives from the backend down to the client over UDP. Implement the client, server and backend in Golang and Terraform such that it scales to more than 1M clients. Provide estimates of the cost to run the solution each month at a steady load of 1M clients, as well as some options you would recommend as next steps to reduce the cost. IMPORTANT: When you load test this system, make sure you are communicating between the client, server and backend using internal addresses to avoid egress bandwidth charges."
  - dilyevsky 3y ago
    Ok so if NAT punch-through is not needed I guess the only tricky thing is connection pooling on the backend side? I sort of agree with the other poster - that if you had done something like this before it's trivial and if you haven't, it's a bit hard to research on your own.
    - gafferongames 3y ago
      100%. There is a class of programmer for whom this would be a toy problem. There is another class of programmer who may be young or not directly experienced in this space, but who is very intelligent and an excellent problem solver and is willing to work hard. The question was designed to find both types of applicants.

nyrikki 3y ago

As posed, this problem is a toy one and fairly easy. 1) The arrival rate is constant, vs the more realistic Poisson distribution 2) The response fits in a single packet 3) Requests are consistent size. I don't think most companies are going to have the resources to take advantage of QUIC and HTTP/3 for a while. While head of line blocking is theoretically gone, most programming is based around ordered delivery. I see lots of projects doing single streams to minimize complexity, but that severely reduces large asset transfer. I am sure the FAANG crew will gain a lot of advantages, but tooling needs to be there for the rest of us. Obviously some will take advantage of it, but it is a shift in responsibility to the application and dealing with window scaling and out of order delivery is expensive. IMHO, UDP is simply a target because legacy systems would make a new option that was superior difficult if impossible to implement. As I have supported voip and streaming over the public Internet, I admittedly have a jaded view. But I am not looking forward to supporting the quirks of every client when it was easy to hand that off to the OS. Hopefully I am wrong, and SWEs will be good at dealing with ood and random failures and standards will offload the cost of implementing what TCP gave us for free. But I don't think people realize how easy reliable, ordered delivery makes programming.