The perspective here is subtly baised - look at the diagram down the bottom and realise that they were always only going to hire 1 person, so all the reasons that they give for not hiring the person are, in fact, not reasons that the person filtered out wasn't hired. They are processes to rank the applicants. If there were more candidates they'd add more reasons not to hire most of them, if there were less candidates the reasons not to hire would start to disappear.

In particular, companies are in some sense bluffing with the "Didn't Qualify" category. I've seen hiring situations where nobody qualifies but they actually need to fill the position - they hired someone who didn't qualify and trained them up. They did a great job. "Didn't qualify" is only a real category for the most demanding jobs. Software is just not one of them, nobody has any idea if dev is going to be good or not before they hire them. Companies often have a hard time picking which devs are the productive ones when they've already hired the dev.

So we've got an article about a process used to rank devs, and no particular evidence of whether the dev hired is actually very good. Which is fine, still an interesting read. But it is good to keep a clear perspective. This is one of those situations where doing big parts of the process by fair dice roll is not necessarily an inferior approach.