There are very, very many comments here accusing HackerRank and/or puzzle/algorithm problems in general of being poor tests for how good a programmer someone is, or that people who use such problems just want "robot" workers to churn out meaningless code.<p>These comments are completely missing the point. HackerRank's value is as a <i>screening</i> process. The point of such problems in the early phases of an interview is not to find out how <i>good</i> a programmer you are, but how <i>bad</i> a programmer you are.<p>There are an ASTOUNDING number of candidates for programming jobs who can barely code. FizzBuzz eliminates a lot of them, but sometimes you need something just a <i>bit</i> more difficult. That's where HackerRank comes in.<p>When talking to people that are "professional programmers actively seeking work" I find that the majority of them can't do simple tasks. "Simple" isn't meant in an arrogant way, either; examples include reversing an array (with no space constraint), iterating a dictionary/map (regardless of understanding map implementation, a lot of people don't understand that iteration order isn't predictable), and basic use of nested lists/non-scalar data structures. Those aren't esoterica that "nobody uses" on a daily basis, they're bread and butter of programming work.<p>These people have hobby projects/OSS work, it's just . . . not sufficient, in many cases, to indicate basic competence on the job. I don't know why that doesn't correlate. I don't think most of these people are lying and publishing work that isn't theirs. It might be that they have a very long time to write the stuff in their GitHubs or whatever and can't do basic things in a hurry otherwise. It might be something else. Regardless, they turn out to be unqualified when tested on the basics.<p>If you find the problems insultingly easy, choke it down and consider it equivalent to the question of "are you comfortable being asked to show up to work on time?"--patronizing, but an easy box to check, and not meant for you.<p>There are companies that rely entirely on very hard/complex algorithms problems for interviewing, with the full knowledge of what they're testing for and why they're using those tests. I'm not talking about those companies; there are good and bad reasons for doing that. I'm talking about simple coding challenges presented early on in the candidate's process.<p>There are also companies that get confused as to what they're using the HackerRank-equivalent tests for, and give really hard problems (or, worse, puzzle problems that block all progress and rely on some sort of "gotcha" trivia knowledge to even approach), but evaluate candidates' performance as if those problems were FizzBuzz++ basic competence screenings. That's a mistake, but also not what I'm talking about here.