We've been using the same challenge for that long, because it gives us good comparative metrics versus prior submissions in many regards. It's unique to us. (And yes, we have a list of all the usual places where the solution may be "borrowed" from.)
I understand that, and it has its merits, but the "usual places the solution may be 'borrowed' from" is sure to grow if the challenge doesn't evolve (I just watched a YouTube vid last night of a guy sharing every coding challenge he's ever done). I'm also not convinced that metrics are very useful when it comes to ranking creativity (even if, despite the Rockets' recent embarrassment, I still believe in Moreyball).
Also, personally, I secretly hope (I guess not so secretly, since I keep saying it on Dev and LinkedIn) that candidates are searching to "borrow" at least bits and pieces of the solution (the code review follow-up is where they prove knowledge of how the solution works, regardless of whether said solution is 100% original or not). I need to know that they know when it's unnecessary to reinvent the wheel.
FWIW I'm not at all excusing his attempt to bullshit you, and I applaud you for giving take-home challenges instead of utterly useless (for the hiring company, and pointlessly sadistic to the candidate) timed, on-the-spot challenges.
We're aware of all of that, and yes, learning how others solve it is fine. We see some similar techniques, and certainly plenty of developers use libraries or common patterns, especially for the more predictable components. It is smart.
We're mainly on the lookout for two problems in that area: (a) people who copy/paste someone else's code — we've only ever had two candidates ever do that, mind you — and (b) people who copy/paste together code with no concept of what it's doing. Neither is amenable to coding-as-a-career. Situation (a) is easy to check with a web search, and situation (b) is exposed with the live coding that expands on the code they submit.
(P.S. We also know how to factor in nerves. They're actually a good sign: it means there's a human being there, who knows they're not perfect. It's the people who blaze through live coding with nose held high that worry me, and needfully so, as I learned the hard way over the years that they are always unteachable and toxic.)
But, returning to the original premise, there has been many an interview where, as they fix a bug live in their coding challenge submission, I'm quietly hoping they'll remember some built-in component that handles something for them. Often I will even give them a hint to that effect after giving them a few minutes to think of it themselves. After all, the entire purpose of both the take-home and live coding is to demonstrate how they work through a problem, handle natural roadblocks, and accept suggestions. I don't even expect them to necessarily fix the bug or finish the change in the live coding. I just want to see them try; it tells a lot about them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We've been using the same challenge for that long, because it gives us good comparative metrics versus prior submissions in many regards. It's unique to us. (And yes, we have a list of all the usual places where the solution may be "borrowed" from.)
I understand that, and it has its merits, but the "usual places the solution may be 'borrowed' from" is sure to grow if the challenge doesn't evolve (I just watched a YouTube vid last night of a guy sharing every coding challenge he's ever done). I'm also not convinced that metrics are very useful when it comes to ranking creativity (even if, despite the Rockets' recent embarrassment, I still believe in Moreyball).
Also, personally, I secretly hope (I guess not so secretly, since I keep saying it on Dev and LinkedIn) that candidates are searching to "borrow" at least bits and pieces of the solution (the code review follow-up is where they prove knowledge of how the solution works, regardless of whether said solution is 100% original or not). I need to know that they know when it's unnecessary to reinvent the wheel.
FWIW I'm not at all excusing his attempt to bullshit you, and I applaud you for giving take-home challenges instead of utterly useless (for the hiring company, and pointlessly sadistic to the candidate) timed, on-the-spot challenges.
We're aware of all of that, and yes, learning how others solve it is fine. We see some similar techniques, and certainly plenty of developers use libraries or common patterns, especially for the more predictable components. It is smart.
We're mainly on the lookout for two problems in that area: (a) people who copy/paste someone else's code — we've only ever had two candidates ever do that, mind you — and (b) people who copy/paste together code with no concept of what it's doing. Neither is amenable to coding-as-a-career. Situation (a) is easy to check with a web search, and situation (b) is exposed with the live coding that expands on the code they submit.
(P.S. We also know how to factor in nerves. They're actually a good sign: it means there's a human being there, who knows they're not perfect. It's the people who blaze through live coding with nose held high that worry me, and needfully so, as I learned the hard way over the years that they are always unteachable and toxic.)
But, returning to the original premise, there has been many an interview where, as they fix a bug live in their coding challenge submission, I'm quietly hoping they'll remember some built-in component that handles something for them. Often I will even give them a hint to that effect after giving them a few minutes to think of it themselves. After all, the entire purpose of both the take-home and live coding is to demonstrate how they work through a problem, handle natural roadblocks, and accept suggestions. I don't even expect them to necessarily fix the bug or finish the change in the live coding. I just want to see them try; it tells a lot about them.