4 ms·

It's good to see this problem getting attention. Hackerrank et al are just leetcode with a HR system integration. They're optimised entirely for the business, n

It's good to see this problem getting attention. Hackerrank et al are just leetcode with a HR system integration. They're optimised entirely for the business, not the candidate. It misses the point that there is a human aspect to this, too, and not everything should be fully automated. It has happened more times than I'd care to admit that somebody has passed an interview that I've run following company guidelines (always some algorithm puzzle on a whiteboard) and they've been terrible at the job. It sucks for everybody, the new hire and their team, too. Other times I've been on the fence about somebody in an interview and they turn out to be amazing. One thing that worries me is that I see "projects" as a test option with this. It's just as much of a problem where companies give candidates projects saying that it should only take a few hours when, in reality, it could take days. That's time that not everybody has on top of a full time job.

dmkirwan 4y ago
I fully agree. We don't have anything in place at the moment to stop users from adding private projects that take a huge amount of time to complete, but we are going to spend time on helping to guide customers away from that situation. I think a large reason for people spending lots of time on code projects boil down to two things: 1) the people who create the test never actually do it themselves, and only estimate how long they think it will take, and 2) Companies don't give enough guidance on what is needed and what isn't. If it's too open-ended then how does a candidate know when to stop? We made the decision early on to aim for solutions that work well for both the candidate and the company, but where they conflict, go with what will work best for the candidate. This may seem counterintuitive from a business perspective, but it has served us well and, I think, it is the best way to go long term. Ultimately if we can give a great candidate experience then that's good for the business too.

dmkirwan 4y ago

I fully agree. We don't have anything in place at the moment to stop users from adding private projects that take a huge amount of time to complete, but we are going to spend time on helping to guide customers away from that situation. I think a large reason for people spending lots of time on code projects boil down to two things: 1) the people who create the test never actually do it themselves, and only estimate how long they think it will take, and 2) Companies don't give enough guidance on what is needed and what isn't. If it's too open-ended then how does a candidate know when to stop? We made the decision early on to aim for solutions that work well for both the candidate and the company, but where they conflict, go with what will work best for the candidate. This may seem counterintuitive from a business perspective, but it has served us well and, I think, it is the best way to go long term. Ultimately if we can give a great candidate experience then that's good for the business too.