But how do you know that the candidate actually couldn’t do the job versus just blowing your challenge for some reason? What may seem “simple” to the engineers that make up the challenge (therefore clearly knowing the answer) and who are comfortably safe (theoretically) in their positions, may not seem so simple to someone coming at the question cold, especially if they have test anxiety or feel pressured to make something work out so they can just earn an income. And how do you know that everyone who passes this test can actually do well at the job? Was the test actual realistic work that the candidate would do? Maybe a candidate aces the challenge but then just does the minimum work possible to keep the job?
yukster
D4no0
Sadly I observed this happening a lot of times and this applies not only to coding challenges but to questions also.
People tend to ask about some challenging things from their projects, that they stayed and solved for months or maybe years and expect you to answer like you worked with them, and the anxiety and lack of care from interviewer doesn’t help at all…
2
sodapopcan
This is exactly why I think you should keep things simple. Like basic programming concepts, then ramp up the difficulty slowly to get a better idea of where they’re at. It should really be primarily measuring “what is this person like to work with” while filtering out people who claim to be programmers but don’t know what a function is (this sounds extreme but it’s happened to me).
2
BartOtten
As I came in the business of writing code while using only 3 fingers per hand, it’s actually hard to learn full blind typing. Muscle memory is hard to change especially when you are focussed at solving a problem (then muscle memory takes over the hands). If someone wants to sponsor me for a month ‘slow but getting there eventually’ I am all ears 
0
BartOtten
So questions and tests should be specific to get the best programmer (tool) for the job. There is not one list that will cover all.
Some brilliant developers I know soon derail when not in a team with some less brilliant-coders that are better at abstracting “the real issue” out of the feature request, combine them with other features on the backlog (using knowledge of the code base) or can write near perfect documentation. So at our company we mix ‘kinds of developers’ for the best result.
I am the ‘lesser coder’ in my team so I tend to have a major imposter syndrome while programming. But I am sure the team would not function without me, our product has more value due to my work and I can do many things they can’t. Would be a shame if I was rejected based on an algorithm test (we don’t write complex algorithms anyways)
Ps. Just see how novice Elixir developers tend to cause improvements to the documentation. Simply because they are unable to “just read the source code”. Those improvements ain’t code but it is a major part of what makes Elixir great (and accessible by more devs than only those x10’s)
6