Issuing false takedowns against organizations whose code you use for free is a pretty bad look.
(It's also a pretty crummy product, I used to use it as an interviewer and am glad I no longer have to.)
> So, I generally have a personal rule against disparaging things that other people made because I know how hard it is to make stuff and how criticism feels. I ignored that rule in this instance only because I've been a victim of DMCA misuse from a company and have learned the hard way that the only real repercussions anyone will face are reputational.
> For context on my experience with HackerRank, I have used both the take-home test product and the real-time test product. It has been almost a year since I have used either, since I left that job.
> I found the real-time product frustrating to use; frequently I could not rely on the candidate seeing the same state I did. I forget exactly what the problem was but candidates were often confused by the console not appearing and things like that. In some instances, either I or candidates were booted out of an interview in progress and had to refresh the page. Usually we worked it out pretty quickly, but losing precious time can make candidates nervous and it's not a great first experience with the company for them. I also found that code execution ran slowly, in both the real-time product and the take-home test -- we weren't running big programs, I'm not sure what was so slow.
> On the take-home side, for context, I was one of several people responsible for the take-home coding test for my department and was also (unofficially) the go-to person to look into assignments that were flagged for plagiarism. I found the plagiarism detection results to be pretty incomprehensible -- sometimes I'd see tests with very high plagiarism scores and no signs of obvious plagiarism, or things like a 90% score with just a few innocuous lines of overlap with the alleged source. I understand that flagging false positives for human review is generally preferred here to false negatives, but my main concern here is that if recruiters within an organization take these numbers at face value, they end up rejecting candidates pretty much randomly, or because the candidate wrote idiomatic code that looks like everyone else's because it's the idiomatic solution in that language.
