The most reliable way to evaluate programmer candidates is to hire them to do a bit of realistic work. This is widely understood, but not widely practiced.

The biggest barrier is finding projects for them to work on. In most organizations, the overhead of getting a new person started is too high to justify handing even the smallest slice of real work off to a candidate. For examples, in "The One Method I’ve Used to Eliminate Bad Tech Hires", Amir Yasin writes:

RULE #2 — DON’T use a real problem because of tribe knowledge needed to fix.

But this rule is missing a key opportunity: there are tribes much bigger than your company. When you share knowledge and conventions across a wider community, a new person can come into your team and instantly be productive. That is how things actually work in the Ember community.

It's entirely normal to hand someone with Ember experience access to a Git repository they've never seen before and instructions to add a small new feature, and to get back working code in hours. Code that actually fits in with "how we do things here". That's the value of having strong conventions.

That's great for hiring intermediate-to-advanced developers, but what about junior-level people? Conventions shine there too, because you can reach for off-the-shelf teaching materials to get them rolling.

The cost of learning & training never disappears, but the key trick here is broadly sharing the cost. Each time you force developers to make a curation decision with multiple valid answers, you fragment the pool of people who can share this cost. It makes it much harder to have comprehensive teaching books or libraries of training videos.

That is why I'm so happy with the massive level of investment the Ember community pours into shared solutions. Shared solutions are harder to create than one-offs, but they're incredibly valuable.