3 ms·

Take-home tests are the worst. This is why: - it doesn't value equally candidate's time and company's time. The candidate has to spend hours/days to do the tes

by danwee 4y ago

Take-home tests are the worst. This is why: - it doesn't value equally candidate's time and company's time. The candidate has to spend hours/days to do the test, while the company evaluates the result in minutes (1h at most) - they are always open-ended, so you can always do more... that means the more hours you put on it the higher the chance of passing. So, if I spend 4h, but you spend 10h, all things equal, you got the job - if they are underspecified and you dare to ask questions... be ready for a huge email-thread coming and long waiting times (in the order of hours instead of in the order of seconds/minutes as it would be the case if you were doing the test "online" with them) - if you ask questions: how many questions is good enough? Maybe I'm asking too many? Or too few? I cannot really tell by the way they write their email answers to me (I could tell if I were asking the questions in a video-call, though... but damn it, this is a home-take test!)

kube-system 4y ago
Companies that do take homes that way are bad. They don't have to be done that way. They should be limited in duration intentionally to respect people's time and to keep things fair between candidates.
- 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'.
otherme123 4y ago
I remember reading a blog entry from a recruiter that did exactly the second point: he gave a task to be done in 3 hours, a couple of candidates not only did the task but worked for more than 10 hours doing extra fancy that had nothing to do with the main task and telling the recruiter they overworked. They were hired, the recruiter loved the extra mile. What if a candidate is way better but cannot spend 10 hours in an interview? Is it actually a good trait to spend three times the time allocated in bells and whistles?

by danwee 4y ago

kube-system 4y ago

Companies that do take homes that way are bad. They don't have to be done that way. They should be limited in duration intentionally to respect people's time and to keep things fair between candidates.

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'.

otherme123 4y ago

I remember reading a blog entry from a recruiter that did exactly the second point: he gave a task to be done in 3 hours, a couple of candidates not only did the task but worked for more than 10 hours doing extra fancy that had nothing to do with the main task and telling the recruiter they overworked. They were hired, the recruiter loved the extra mile. What if a candidate is way better but cannot spend 10 hours in an interview? Is it actually a good trait to spend three times the time allocated in bells and whistles?