4 ms·

In the past when doing timeboxed, we gave the candidate a weekend. The task was too much work for a weekend, but that's part of the job. Choosing to prioritize

In the past when doing timeboxed, we gave the candidate a weekend. The task was too much work for a weekend, but that's part of the job. Choosing to prioritize and what to prioritize is also an important skill. In our case: if you were going for the perfect code abstraction but didn't deliver any business value in the form of a working product, that says something about the candidate and their performance in a team.

detaro 9y ago
I hope you communicated that clearly beforehand?
- mathgeek 9y ago
  This! I've done more than one code challenge in my time that was secretly testing for how far you get on a task that is underbudgeted on time. Your best applicants are going to spend too much of their own (unpaid) time finishing it and be annoyed at you before you tell them how clever you are for testing their ability to prioritize...or they're just going to not bother.
  - watwut 9y ago
    I would assume this is how the company will treat me after being hire.
    - scaryclam 9y ago
      Far too many companies forget that they are also being tested and interviewed. The sort of stupid "let's secretly test whether the candidate can figure out we're screwing with them" kind of thing lets good candidates know one thing: the company is toxic and won't treat them like a human. This is the exact sort of behavior to run away from.
- jpmoyn 9y ago
  Yeah because most peoples biggest priority going into in a technical interview process is focusing on good code. If they want a candidate to "MVP" their coding challenge for business value reasons, they should make that very clear. It's not like it takes MORE skill to write hacky code.
- joelhaasnoot 9y ago
  Definitely
bpicolo 9y ago
Do you tend to give a two day deadline in the workplace and then expect the deadline to not be met?
- joelhaasnoot 9y ago
  We were open and honest about it being too much. The pattern that emerged is that it allowed us to see the candidates' strengths. Some didn't tackle the backend part: that was not their forte (and we hired them and sent them off on a course). Also, in any IT job I've worked there's generally more business requirements/wishes/etc than can be finished. That's a fact of life. It helps to have team players that have are independent and give some push back where needed, as well as realistic deadlines. There were some that handled the deadline badly, that didn't help their case. (but apparently, many believe giving someone a task to do is not done)
  - bpicolo 9y ago
    I guess what I'm saying is the expected reaction to this in the work place would be to trim the requirements and set expectations before you ever start work. If that's part of the test, cool, but it seems like that wouldn't be something a candidate would assume heh.
Double_a_92 9y ago
Do you want crappy code that get's harder and harder to extend and maintain? Because that's how you get that.
- joelhaasnoot 9y ago
  Correct, but time to market has it's value too. Also: mobile dev so Apple forces a rewrite every couple years anyway (on both design and tech fronts)

detaro 9y ago

I hope you communicated that clearly beforehand?

mathgeek 9y ago
This! I've done more than one code challenge in my time that was secretly testing for how far you get on a task that is underbudgeted on time. Your best applicants are going to spend too much of their own (unpaid) time finishing it and be annoyed at you before you tell them how clever you are for testing their ability to prioritize...or they're just going to not bother.
- watwut 9y ago
  I would assume this is how the company will treat me after being hire.
  - scaryclam 9y ago
    Far too many companies forget that they are also being tested and interviewed. The sort of stupid "let's secretly test whether the candidate can figure out we're screwing with them" kind of thing lets good candidates know one thing: the company is toxic and won't treat them like a human. This is the exact sort of behavior to run away from.
jpmoyn 9y ago
Yeah because most peoples biggest priority going into in a technical interview process is focusing on good code. If they want a candidate to "MVP" their coding challenge for business value reasons, they should make that very clear. It's not like it takes MORE skill to write hacky code.
joelhaasnoot 9y ago
Definitely

bpicolo 9y ago

Do you tend to give a two day deadline in the workplace and then expect the deadline to not be met?

joelhaasnoot 9y ago
We were open and honest about it being too much. The pattern that emerged is that it allowed us to see the candidates' strengths. Some didn't tackle the backend part: that was not their forte (and we hired them and sent them off on a course). Also, in any IT job I've worked there's generally more business requirements/wishes/etc than can be finished. That's a fact of life. It helps to have team players that have are independent and give some push back where needed, as well as realistic deadlines. There were some that handled the deadline badly, that didn't help their case. (but apparently, many believe giving someone a task to do is not done)
- bpicolo 9y ago
  I guess what I'm saying is the expected reaction to this in the work place would be to trim the requirements and set expectations before you ever start work. If that's part of the test, cool, but it seems like that wouldn't be something a candidate would assume heh.

Double_a_92 9y ago

Do you want crappy code that get's harder and harder to extend and maintain? Because that's how you get that.

joelhaasnoot 9y ago
Correct, but time to market has it's value too. Also: mobile dev so Apple forces a rewrite every couple years anyway (on both design and tech fronts)