An employer asked me to do a HackerRank test. Here's my alternative proposal.

These comments are completely missing the point. HackerRank's value is as a screening process. The point of such problems in the early phases of an interview is not to find out how good a programmer you are, but how bad a programmer you are.

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 bit more difficult. That's where HackerRank comes in.

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.

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.

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.

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.

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.

I tried to build my own coding test that is based on refactoring based on changing requirements: https://alexrohde.com/public/zennish/index.html#/challenges

Some tests will seem impossible to complete in the alotted time. Often that's intentional. It saves time for the candidates and gives a better spread of scores (very few will get 100% in some test batteries). But it can be disheartening. For these initial online tests I try to give enough time that most people won't really run out of time unless they get stuck.

A minimal bar test shouldn't take 90 minutes. If you want a test like that, ask a FizzBuzz question, which is solvable in ten seconds and will be just as good a discriminator. Asking people to basically solve riddles isn't productive.