The Takehome problem approach should be the way to interview everybody IMHO. Ask candidates to solve a problem in a job ad, use that code to continue the interview process. Instead of the usual hr_phone_interview-meet_manager-meet_team-code_test-meet_Some_VP-get-offer way
I think that would work until someone posts the solution online and everyone is submitting the same code, effectively turning it into an unscreened interview.
Of course, the next step is to do an in person interview and drill the candidates on their work and choices they made. It's very difficult to get through the second stage when the first one was accomplished by cheating.
Interesting that just a few weeks ago we had this exact situation. A candidate was copy pasting blindly some SO code verbatim. Now days, it's easy and fast to find out where the code is copied from :)
Finally, change the test projects with each hiring session so that they sufficiently different.
@molly_struve
and @rommik
: Finally, I find others on DEV who do the same thing I've been doing for years: a take-home coding challenge, which is further discussed in the final interview.
@etampro
I don't know about other teams, but I keep an archive of all previous solutions, and also do web searches. I have spotted copy/paste answers before. In any case, such applicant always falls apart when the final interview comes around, because they don't actually know the code well enough to modify it live.
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.
The Takehome problem approach should be the way to interview everybody IMHO. Ask candidates to solve a problem in a job ad, use that code to continue the interview process. Instead of the usual hr_phone_interview-meet_manager-meet_team-code_test-meet_Some_VP-get-offer way
I think that would work until someone posts the solution online and everyone is submitting the same code, effectively turning it into an unscreened interview.
Of course, the next step is to do an in person interview and drill the candidates on their work and choices they made. It's very difficult to get through the second stage when the first one was accomplished by cheating.
Interesting that just a few weeks ago we had this exact situation. A candidate was copy pasting blindly some SO code verbatim. Now days, it's easy and fast to find out where the code is copied from :)
Finally, change the test projects with each hiring session so that they sufficiently different.
@molly_struve and @rommik : Finally, I find others on DEV who do the same thing I've been doing for years: a take-home coding challenge, which is further discussed in the final interview.
@etampro I don't know about other teams, but I keep an archive of all previous solutions, and also do web searches. I have spotted copy/paste answers before. In any case, such applicant always falls apart when the final interview comes around, because they don't actually know the code well enough to modify it live.