3 ms·

That doesn't work either. If I send you a take-home test and I set the duration of it to be 3 days: what if you (think) you are done in 4 hours? Will you just s

by danwee 4y ago

That doesn't work either. If I send you a take-home test and I set the duration of it to be 3 days: what if you (think) you are done in 4 hours? Will you just send it? Or will you spend more time on it because, well, maybe other people are spending the actual 24*3 hours on that take-home test? Maybe they add documenation that can be viewed directly in the command line? Maybe they add a better (bigger) set of test cases? Maybe they even go further the specs of the problem and hand over an actual reusable piece of library (which you didn't because based on your judgment, the task could have been done in 4 hours easily, without the need to write a library out of it, and so that's what you did rightly). Take-home tasks are the wrong solution to this difficult problem of our that is hiring.

kube-system 4y ago
All of those durations are way too long. 2 or 3 hours is pushing it. That is plenty enough time to determine whether a candidate can write code.
leoedin 4y ago
The duration should be hours, not days. The way I've done it in the past is by pre-arranging with the candidate a time that they'd like to do the test (maybe 7pm on a Tuesday, or 3pm on a Saturday). They're sent some details of the development environment and guidance before hand. Then they're sent the test at that time and then have to send the result back within 3 hours. I suppose that still selects for people who have 3 contiguous hours to spare. But it feels to me to be the fairest solution - it doesn't reward people who have endless time, and it doesn't subject poor candidates to open ended misery. Sending the dev environment stuff before hand gives them time to make sure it's working first - and an opportunity to ask questions about the environment if anything is unclear. It definitely shouldn't take 2 hours to set up a development environment - if that's the case then it's either an inexperienced candidate or very poor instructions.
- kube-system 4y ago
  Rather than making people commit to a time window, I've always done the honors system with good results. If you judge the result on quality rather than quantity it doesn't even matter if people try to 'cheat'.

by danwee 4y ago

kube-system 4y ago

All of those durations are way too long. 2 or 3 hours is pushing it. That is plenty enough time to determine whether a candidate can write code.

leoedin 4y ago

The duration should be hours, not days. The way I've done it in the past is by pre-arranging with the candidate a time that they'd like to do the test (maybe 7pm on a Tuesday, or 3pm on a Saturday). They're sent some details of the development environment and guidance before hand. Then they're sent the test at that time and then have to send the result back within 3 hours. I suppose that still selects for people who have 3 contiguous hours to spare. But it feels to me to be the fairest solution - it doesn't reward people who have endless time, and it doesn't subject poor candidates to open ended misery. Sending the dev environment stuff before hand gives them time to make sure it's working first - and an opportunity to ask questions about the environment if anything is unclear. It definitely shouldn't take 2 hours to set up a development environment - if that's the case then it's either an inexperienced candidate or very poor instructions.

kube-system 4y ago
Rather than making people commit to a time window, I've always done the honors system with good results. If you judge the result on quality rather than quantity it doesn't even matter if people try to 'cheat'.