All the caveats this candidate mentioned about standard coding screens are true, but they can all also be taken into consideration by qualified interviewers.
There are flaws in this candidate's proposal too. In particular, their proposal does not satisfy their implicit criteria that the interview should mirror real-world conditions, because they chose their own projects with which they are already intimately familiar but the job most likely consists of working on a pre-existing codebase that they know nothing about.
Real world conditions like these?
>> (1) time limits, (2) forbidding research on Wikipedia or StackOverflow, (3) forbidding collaboration, and (4) forbidding the use of libraries
There is no mention of "working on a pre-existing codebase that they know nothing about" in the description of the HackerRank test... so I don't know how your point applies?
Yet by forbidding the use of external research and libraries they remove the two main tools I would want some to use "in an environment and context where you don't have the advantage of being an expert ahead of time"
The problems should be chosen such that external research and libraries are not needed. For our phone screens, we don't even require the code to compile or successfully run. For instance, we explicitly tell candidates to just make something up that sounds reasonable if they need a standard library function that they know exists but they can't remember its exact name or type signature.
We've never used HackerRank, so I don't really know how customizable it is. From the comments here, it sounds like it's designed to be fully automated with no participation from any developers at the hiring company. I don't like that at all. When I wrote my original comment, I'll admit I was thinking of it as a more advanced Google doc for programming, not as a fully automated platform. That's my bad, and I should have done my research a bit more.