"The thing with 4hr technical assignments is that you're saying no to anyone with kids"
Is 4 hours the amount of time the candidate is being given to complete it, or roughly how long the employer expects it will take?
In the past I've generally come up with tests I know can be done in an hour or so (2 tops), but allowed 24 hours, exactly because not everyone is going to be in a position they can dedicate those 2 hours to it right there and then.
Sure, those that did take the full 24 hours to complete I tended to apply higher expectations towards when judging, but at the end of the day it didn't make much difference - the tests were only to weed out those that had clearly made a poor career decision (and there were surprisingly many of those, to the point we switched to testing before interviewing).
> "The thing with 4hr technical assignments is that you're saying no to anyone with kids"
> Is 4 hours the amount of time the candidate is being given to complete it, or roughly how long the employer expects it will take? In the past I've generally come up with tests I know can be done in an hour or so (2 tops),
Have you actually given these assignments to some of your colleagues and asked them to complete and how long it took (including setting up the development environment ...)? People are notoriously bad at estimating time it takes someone else to do something that oneself is intimately familiar with. So I would not be surprised that the assignments took more like 2-4 h, if you add the additional time for context switching, organising to free your schedule etc..
> but allowed 24 hours, exactly because not everyone is going to be in a position they can dedicate those 2 hours to it right there and then.
I don't think the GP was implying that the assignment was to be done right there and then, where and when would you do those 2 h in their schedule?
> Sure, those that did take the full 24 hours to complete I tended to apply higher expectations towards when judging,
So for someone with kids etc., who couldn't do the assignment straight away you actually expected more than 2h worth of work? To me that's already a red flag that you don't respect peoples life-work balance.
> but at the end of the day it didn't make much difference - the tests were only to weed out those that had clearly made a poor career decision (and there were surprisingly many of those, to the point we switched to testing before interviewing).
Unless you offer exceptionally high salary or are a highly desirable place to
work at, you are likely not getting the best applicants.
Take home test as the first step in an interview process is the ultimate evil in this. I've spent hours then got ghosted. I will never do it again. This is a "run like hell" signal imo.
I've heard that before, and if we felt there was a significant risk we were putting off good devs from applying, I'd reverse that decision.
But I like to think we made our tests a fun & interesting enough challenge that applicants were happy to spend the time doing them.
This might be fine for hiring juniors but I can't imagine many experienced applicants would be interested in gambling their time away on your test before any interview.
Actually I've never been heavily involved in hiring a junior. Even at my own level (>26 years prof. experience) I'd happily do a test before a formal interview (though I'd likely want a brief chat with someone from the company to get a feel for what sort of shop they run first). And I would be judging the employer on the quality of their test.
I've read some. Doesn't align with my personal experience is all I can say. I can't remember a case where a candidate refused to do such a test, or that we never heard back from after letting them know that was our policy.
Possibly, but we introduced the policy simply because too many candidates were using up our time with interviews where they appeared to be knowledgeable etc. but then quickly demonstrated with the take-home test that weren't going to be a good fit for us. I'll be honest, there weren't really enough data points to take any grand conclusions from the experience, and this was all pre-covid etc. I'm moving to a new role soon and I'm expecting to get back into being more actively engaged in screening new hire candidates etc., so I'm sure I'll learn more as I go - some of the points raised in this forum have definitely given me pause for thought.
Instead of allowing 24 hours, I prefer to agree on a start time with the candidate, schedule the email to go out at that time and expect to receive the reply two hours later. That way everyone has the same amount of time.
Yes, I'd used that method too, but I'm not sure how many developers do their best work when told they have 2 hours max to complete any task. In fact we never put any recommendations on how long the task should take, just that they had a 24-hour window in which to come up with the best submission they could. In some (rare) cases submissions that didn't technically complete all the requirements exactly were considered more favorably than ones that did.
Is 4 hours the amount of time the candidate is being given to complete it, or roughly how long the employer expects it will take? In the past I've generally come up with tests I know can be done in an hour or so (2 tops), but allowed 24 hours, exactly because not everyone is going to be in a position they can dedicate those 2 hours to it right there and then. Sure, those that did take the full 24 hours to complete I tended to apply higher expectations towards when judging, but at the end of the day it didn't make much difference - the tests were only to weed out those that had clearly made a poor career decision (and there were surprisingly many of those, to the point we switched to testing before interviewing).