2 ms·

I would have failed your test. I'd have assumed that you didn't want your server inundated by requests, set up my own server to verify what my client was doing,

I would have failed your test. I'd have assumed that you didn't want your server inundated by requests, set up my own server to verify what my client was doing, and then submitted the code. Even if you specifically told me that I must actually hit your server, I'd still test on my own server, and then possibly forget to change the endpoint before submitting (no way to unit test that). Shit happens, and you lose someone on a technicality. Also, what if your server stops working? Now you're wasting people's time. Don't rely on magic; it eventually bites you in the ass.

insomniacity 8y ago
Not GP, but I would say that lack of attention to detail is a negative mark. Depending on GP's industry or team, that could be a dealbreaker. If you can't connect to the server, or it returns a fatal HTTP error, a reasonable candidate would reach out via other means (assuming they aren't deliberately hidden or unavailable).
- EnderMB 8y ago
  We had covered all of these eventualities. We had an uptime badge on the repo to say whether it worked or not, and we encouraged developers to tag us on a GitHub issue or email us directly if something seemed wrong. We were also keen to stress that this should take far less than an hour of their time. We didn't want to see dependency injection, metaprogramming, or anything overboard that showcased a developers knowledge - this is purely just to see if they can deliver code that matches a requirement in the time provided. In the case where we had downtime (once in 18 months), I just forwarded their email to HR and we spent some extra time going over code in the sit-down interview.
- ManlyBread 8y ago
  If I would see that the server is unreachable I wouldn't contact anyone, I would interpret that as a red flag. The company would have no problem with deeming me unfit to work for them if I fail to complete the task - why should I consider working for that company when it's their fault that I'm unable to complete the task? What if this situation illustrates how the company works on the inside (no one takes care of the environments, things are constantly broken)? Is it worth it to find out?
  - Maert 8y ago
    That's a lot of jumping to conclusions. A simple "Hey guys, the server seems to be down, not sure if you're aware. Can you let me know when it's back up so I can submit my request, as intended?" Shows understanding, shows willingness to reach out and solve problems, shows ability to delegate responsibility.
    - ManlyBread 8y ago
      My approach is merely a reverse take on "it is better to pass up a good candidate than to hire a bad one" that most companies seem to utilize. I'd rather refrain from continuing the interview (even if the company wouldn't end up being that bad) than wasting several months in a bad place.
doteka 8y ago
Not OP but sounds like the test is working then. > I'd have assumed... I would expect a good candidate/colleague to ask instead of assuming things. > And then forget to... > Shit happens... If someone can't manage to complete a simple assignment without forgetting half the steps, I don't want them pushing code to production. And a service with one http endpoint having reasonable uptime seems very far from magic.
EnderMB 8y ago
Yeah, you probably would have failed, since you need to hit the endpoint to get the HR email address as a response. Literally, the only point of the exercise is to get that email address. It says that much in the description of the task, alongside raising a GitHub issue if the server is down. It was hosted on Azure, and had our uptime tool checking it anyway. If it was down, there'd be a badge on the repo homepage saying it was down. It happened once, and I invited the person to the interview regardless regardless. I say this much when we send over the technical test. It's like the weigh-in for a boxing match. If they want to showboat, it's on them, but all I care about is whether they can follow a simple instruction with minimal code in the time we said it'd take. I couldn't give a shit what fancy tricks you do in your code, because it's code you've written without time constraints in your own time. The whole reason for chatting about past experience is to see what you do in a REAL development situation.
world32 8y ago
You sound like exactly the kind of person this test is supposed to weed out: making unfounded assumptions, over-complicating things with a resentful attitude and not even completing the very basic thing that was asked of you.

insomniacity 8y ago

Not GP, but I would say that lack of attention to detail is a negative mark. Depending on GP's industry or team, that could be a dealbreaker. If you can't connect to the server, or it returns a fatal HTTP error, a reasonable candidate would reach out via other means (assuming they aren't deliberately hidden or unavailable).

EnderMB 8y ago
We had covered all of these eventualities. We had an uptime badge on the repo to say whether it worked or not, and we encouraged developers to tag us on a GitHub issue or email us directly if something seemed wrong. We were also keen to stress that this should take far less than an hour of their time. We didn't want to see dependency injection, metaprogramming, or anything overboard that showcased a developers knowledge - this is purely just to see if they can deliver code that matches a requirement in the time provided. In the case where we had downtime (once in 18 months), I just forwarded their email to HR and we spent some extra time going over code in the sit-down interview.
ManlyBread 8y ago
If I would see that the server is unreachable I wouldn't contact anyone, I would interpret that as a red flag. The company would have no problem with deeming me unfit to work for them if I fail to complete the task - why should I consider working for that company when it's their fault that I'm unable to complete the task? What if this situation illustrates how the company works on the inside (no one takes care of the environments, things are constantly broken)? Is it worth it to find out?
- Maert 8y ago
  That's a lot of jumping to conclusions. A simple "Hey guys, the server seems to be down, not sure if you're aware. Can you let me know when it's back up so I can submit my request, as intended?" Shows understanding, shows willingness to reach out and solve problems, shows ability to delegate responsibility.
  - ManlyBread 8y ago
    My approach is merely a reverse take on "it is better to pass up a good candidate than to hire a bad one" that most companies seem to utilize. I'd rather refrain from continuing the interview (even if the company wouldn't end up being that bad) than wasting several months in a bad place.

doteka 8y ago

Not OP but sounds like the test is working then. > I'd have assumed... I would expect a good candidate/colleague to ask instead of assuming things. > And then forget to... > Shit happens... If someone can't manage to complete a simple assignment without forgetting half the steps, I don't want them pushing code to production. And a service with one http endpoint having reasonable uptime seems very far from magic.

EnderMB 8y ago

Yeah, you probably would have failed, since you need to hit the endpoint to get the HR email address as a response. Literally, the only point of the exercise is to get that email address. It says that much in the description of the task, alongside raising a GitHub issue if the server is down. It was hosted on Azure, and had our uptime tool checking it anyway. If it was down, there'd be a badge on the repo homepage saying it was down. It happened once, and I invited the person to the interview regardless regardless. I say this much when we send over the technical test. It's like the weigh-in for a boxing match. If they want to showboat, it's on them, but all I care about is whether they can follow a simple instruction with minimal code in the time we said it'd take. I couldn't give a shit what fancy tricks you do in your code, because it's code you've written without time constraints in your own time. The whole reason for chatting about past experience is to see what you do in a REAL development situation.

world32 8y ago

You sound like exactly the kind of person this test is supposed to weed out: making unfounded assumptions, over-complicating things with a resentful attitude and not even completing the very basic thing that was asked of you.