To correlate with job success, you need to define and measure job success. A sub-question: How's the academic research into measuring programmer job success?
Of course software engineering research in general has always been a little unimpressive because what you really need is several teams completing projects, some using method A and others using method B. This could cost millions, and would only settle the bet between methods A and B.
Lacking this, we're left with the publically available research that relies on unconvincing proxies for success and very small samples. It's better than nothing but far short of what we ought to have given how important software is.
Even worse: it would only settle the bet between methods A and B in a particular context.
Also, Google's former head of people (Lazlo Block) founded a company that is focusing on that area: https://humu.com/.
While I wasn't always a fan of Google People/HR procedures while I was there, I did always appreciate the data-driven/research approach Lazlo and the People team took.
I figure that eventually it'll be similar to the Voight-Kampff test and kept on file forever while being shared with all potential employers.
"Because they have to kill their own kind, they constantly need to be assessed as to whether their work is having some kind of moral impact on them'"
In general, there's a lot of research, though with some weird gaps, and a lot of results (though not all) are inconclusive.
A noob could be successful hire and not ultra productive compared to say a more experienced hire.
And that doesn't account for all the places hiring / think they need / hired "rockstar" developers .... to maintain their crud app.
</sarcasm>
Most of the time, what people want isn't even what they want.
It seems gaming trivial metrics works in this case.
2. No one has been able to come up with a better alternative.
I wasn't implying its a prefect metric or even a reasonable one. If you really need a quantifiable metric then thats all we got.