6 ms·
> there's very little left to discourage interviewers from issuing ridiculously time-consuming projects There's also no disincentive for interviewees to spend
by rhinoceraptor 11y ago
> there's very little left to discourage interviewers from issuing ridiculously time-consuming projects
There's also no disincentive for interviewees to spend an unreasonable amount of time on the project. So the test is biased against employed people and/or people with kids.
This can be easily countered though. Send out the assignment at a predetermined, convenient time and require it be returned an hour or two later.
- lewisl9029 11y ago> Send out the assignment at a predetermined, convenient time and require it be returned an hour or two later. This honestly sounds like a great idea to me, except maybe with a slightly longer time allowance to remove some of the pressure. Definitely hoping more interviewers will start to adopt this method for take-home interviews. But this method also hinges on the interviewer's ability to design projects that can be completed in a reasonable amount of time and still give good insight into a candidate's skills. I think it's safe to say this will be a difficult task for most interviewers.
- nsxwolf 11y agoA day or two should honestly be fine. Have them talk about the solution after turning it in. It's a lot easier and more interesting to talk about code you just wrote than it is to make someone whiteboard something on the spot. It doesn't need to be a time trial. If you're impressed with the code and hire the candidate, worst case is you get someone who takes a little more time but writes great code.
- lewisl9029 11y agoThe time requirement doesn't just set a limit for the candidate though, it also serves as a limit to consider for the interviewer when speccing out the project. Having a time limit of a day or two is fine if the actual project should reasonably take a couple of hours, but if the project actually takes more than a whole work day to complete, then that's a different story (in my humble opinion, anything that would take more than a couple of hours is an unreasonable demand on the candidates time unless you offer some kind of compensation).
- draw_down 11y ago> There's also no disincentive for interviewees to spend an unreasonable amount of time on the project. I don't see any problem with this, as an interviewer. The take-home is supposed to be an example of the work the candidate does, they should take however long to do it. I want to see the best-case scenario of the code they write (given the problem at hand, etc, of course). The entire idea is removing the time pressure.
- rhinoceraptor 11y agoRight, but workaday programers with two kids and a full time job won't be willing or won't be able to spend, say more than two hours on something like this.
- deleted 11y ago[deleted]
- timv 11y ago> I don't see any problem with this, as an interviewer. The issue for the interviewer is missing out on good potential hires because your selection process is biased against people with little free time. I have a family and I'm doing part-time study in the evenings. If I'm looking for a new job, then I can probably find time for 1 exercise a fortnight. If one company tells me they have a "4 hour assignment" and the other a "1 hour", then I'm far more likely to do the 1 hour exercise and pass on the long one. And if I do the 1 hour test, I'd expect to be assessed accordingly. If you're comparing one person's output after 1 hour with another who actually spent 5 hours on it, then you will be more inclined to hire the person that spent longer on the project, even though that's not really going to corelate with on the job performance.
- kafkaesq 11y agoSend out the assignment at a predetermined, convenient time and require it be returned an hour or two later. Except that these places very frequently tend to either (1) misstate the problem in some major or minor way, or (2) wildly underestimate the time required to produce a professional quality, bug-free, bulletproof-tested solution. Which can be easily countered by having one of their own team members sit down and take the test first. But of course, none of these places ever do that. (Well, not "none." I'm being hyperbolic. I just mean in that in general, they probably estimate the round-trip time on these programming guizzes the way they do micro-projects on their own jobs -- as in, "Oh, I can do that in an hour" -- but in real life, it often takes 2x-3x longer).
- autarch 11y ago> Which can be easily countered by having one of their own team members sit down and take the test first. But of course, none of these places ever do that. At my employer we send out homework exercises, and I personally did the backend developer exercise before we sent it to anyone. I did this specifically to test how long it took. (For the frontend exercise, we didn't have anyone skilled enough on staff to do it, which is why we were hiring a frontend dev).
- dpark 11y agoDid you do the test blind? i.e. Did someone give you the problem without you knowing/hearing it before? If you wrote the problem, or even heard it before you had to solve it, you had a big leg up on someone who's never heard it.
- autarch 11y agoFair points. FWIW, we've asked people how long the problem took and they all said it took a few hours, so I think it's the right scope. It really is a fairly easy piece of work.
- inanutshellus 11y ago