[nilkn]

Sure, it's very hard to fully approximate that aspect of the job in a quick coding screen. Small algorithmic problems don't come close in the grand scheme of things. But they still put you in an environment and context where you don't have the advantage of being an expert ahead of time.

[shkkmo]

> But they still put you in an environment and context where you don't have the advantage of being an expert ahead of time.

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"

[nilkn]

Sure, that's not ideal. And the more that I read about HackerRank specifically the more I'm convinced it's a step back from boring old phone screens. We do the latter with a Google doc, and while it's technologically primitive in comparison it gives us complete flexibility and ensures the candidate can always ask any questions they have, either about the problem or about the company/job/etc.

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.