We only hire the trendiest

* Our in-person interviews were shorter than typical in-person interviews because they weren't tasked with fully teching candidates out.

* Because they didn't try to tech candidates out, they weren't as stressful, and so were less draining and unpleasant.

* Because our in-person interviews were entirely scripted (the interviewers had very little latitude with what they could ask and how they could ask it --- which they hated, by the way), they were easy for everyone to deliver.

* Before candidates arrived to their interview, they already knew (because we told them!) that they were likely to receive an offer from us based on their performance on the work-sample tests.

I understand why people resist the idea of coding challenges, given:

* They're not going to get feedback for weeks, months, or maybe ever

* The challenge is going to be graded pass-fail, or whimsically, without rigor or consistency

* They're going to have to do the exact same grueling bullshit draining dehumanizing programmer interview anyways

* They're not going to see the challenges coming, or, for that matter, know exactly what happens next after the challenges are done

That process is super common, even at companies that ostensibly do challenges. It sucks. I agree, no company can really get away with this in the long term.

But those are also chickenshit problems. Switching from unstructured interviews to work-samples is hard: you have to change your mindset on how to qualify candidates, and there's a leap of faith involved. But getting candidates feedback, telling them what to expect with your process, keeping a schedule, and having processes in place to be consistent aren't hard problems. They are table-stakes common sense business execution, and if your team can't handle that right now, your team is mismanaged.

Life is too short to worry about things that can't ultimately care about you (weird thing to say I know, but the interests that you care about, even if they are non-human, you fall in love with because they give you something back; and excluding the emotions of: the fear of missing out, the pressure to fit in, or the greed to get ahead).

I'll go out on a limb and say that most of the new Javascript web development frameworks are created by really zealous young people fresh out of school, eager to explore the brave new world of open-source and using Github as a medium to mark their mark (hence the reason for why there are so many new solo frameworks or fork, not enough collaboration); or by old-timers in that community who for whatever personal reasons really enjoy doing it and been doing it. Go to your local open-mic for poetry or music jam for a "In Real Life" representation of this phenomenon.

Speaking for myself, I am just not interested in learning arbitrary new frameworks that isn't intellectually interesting, that is simple syntactical sugar (remapping the textual receipe of rendering of a button from desktop development, to Web 1.0 to Web 2.0 to React.js) or doesn't open up a new outlet to other subjects that I want to learn about (e.g., machine learning, Bioinformatics).

Practically speaking, if it turns out in 5 years, all software companies mandates the banning of lamer frameworks such as PHP or .net and only Node.js/React.js/Flux allowed. I'll wait for the idiot crash guide for these frameworks and these frameworks to be watered for "plebes" like the rest of us and try to learn the keyboard remapping in a couple of weeks; I'll let the hipster kids on Github who "did it first" take the street cred; and hopefully then, I can still manage.

It's also my experience that you get what you pay for, contractors in the whole tend to have a much wider breadth of knowledge from various sectors and hit the ground running whereas I don't tend to see the same appetite from Permanent employees (in most cases!).