Nothing, and that's fine. In fact we encourage candidates to use all resources on our take home interview test. I would probably be impressed if someone setup a hackathon to solve a rather simple take home problem.
A take home problem is simply another signal, and a jumping off point for discussions. If someone used some novel approach we'll discuss it and find out if they actually understand what they did.
The real surprising part is how many take home problems we have received that either do not compile, do not pass the test data we give, or look like the instructions were completely ignored. It ends up as a low effort FizzBuzz on our side.
This sounds great. In my response to another comment I was worried if accepting-but-not-encouraging this kind of behavior would put the interviewees on uneven ground. But if you tell them in advance that basically anything goes, it's fair for all parties.
> The real surprising part is how many take home problems we have received that either do not compile, do not pass the test data we give, or look like the instructions were completely ignored.
Sounds horrible. Though I guess that's only a good thing. Seems like the assignment is doing its job in those cases pretty well :)
Like Fizzbuzz, the point is a quick way filter out candidates.
The interview problem should only serve to be a conversation catalyst. If they got some help with the problem, outsourced the problem or simply googled prepackaged solutions to the problem then they are going to have a really hard time talking through the context of how they solved the problem.
What you're testing for here is communication skills and, if possible, a really basic datapoint that may indicate their technical ability. The latter is very subjective and incredibly difficult to test for but the former is arguably a lot more important if they are going to be working as a part of a team.
Communication skills seem to be held in much lower regard despite them being the key thing for effective day to day work. I can manage / handle working with someone who needs more time than a "rockstar" or hasn't memorized TAOCP if they'are able to communicate effectively. Outside of very specific roles, non-trivial software development is a team effort. It's usually extremely obvious within 15 minutes if a candidate genuinely gets what they've coded or is winging it.
> Outside of very specific roles, non-trivial software development is a team effort.
Couldn't agree more, and I have to say I'm rather baffled that so few recruitment processes are fine-tuned for this. Or maybe I should say that the image one easily gets is so. I myself have had pretty well balanced interviews that also tried to assess things like this, but I've always kind of considered myself just lucky.
When one takes your points into consideration, I can definitely see how having the take-home assignments offer value above the usual whiteboarding+bullshit bingo.
That sounds actually brilliant. While some might argue that this comes back to the "whiteboarding under pressure", honestly if you have already written the code from scratch you definitely should be in a much better position than with the usual "implement a red-black tree insert, you have 15 minutes" whiteboarding tasks.
Seriously though, I guessed that many companies probably must have this kind of laid-back attitude on the matter, since it would be stupid to presume they are ignorant of my original point. Still, I think it might be a little unfair to the people going by the rules-as-written, which somewhat diminishes the consensus of awesomeness of this approach.
That is, if the interview process is not actively trying to choose for hustle... :)
But I'd consider that fairly unlikely. Plus, starting from a position where you don't even trust someone enough to behave like a mature human being isn't a great way to begin a professional relationship.
This makes sure that if someone has not solved home assignment with other's help.
Cool, can they do that for all of their work from now on? Heck, I'll hire all of them if they're that cohesive a team.
A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can probably answer all relevant questions and beyond about the code on the Monday on-site interview.
Sure, that's cheating. And even if it wasn't, I would never do it for the wrong expectations it would set upon me if I actually got the job. But the ease of "embellishing" one's CV always comes up in these threads/posts, and while I wouldn't do that either, I kind of fail to see how this home project approach solves that problem.
Anyone able to ELI5?