|
|
|
|
|
by fzeroracer
2714 days ago
|
|
The extremely obvious problem with this is that there's no way of preventing someone from completely blowing a hole in your interview process by simply paying for or hiring another developer to do the take-home problem for them. At that point they've gotten past the technical requirements and now only need the soft skills to execute on it once the rest of the interview process continues. This is why take-home problems are almost completely irrelevant except for filtering out good candidates. Eventually those problems optimize for perfection which help out those who 'cheat' at the process and people that otherwise put in earnest efforts are rewarded with denials. This is something I've experienced before in my job search where I would put in an honest effort and get 90% of the problem solved, but get denied because my solution wasn't flawless. So allow me to call bullshit on your own claims that this is the right way of determining technical qualifications. |
|
Not all companies handle it like this. I had a take-home exercise as part of an interview last year. I hit a real snag on a fairly small part, I couldn't figure it out, and I ended up leaving a bug in my submission because I simply ran out of time. Very frustrating.
It was raised at the interview; I admitted that I knew it was there, and that I hadn't been able to figure it out. We discussed possible causes: it actually turned into a pretty interesting, though minor, technical conversation. The interviewer eventually told me that he had figured it out after a little investigation (and I expressed my gratitude for the explanation!)
I ended up getting an enthusiastic offer from them.