I took once one job that was offered to many previous candidates. He had rejected it because it was "too complex" for the planed schedule. One of them even wrote a book over the programming language and had many publications, as he did share with me later.
I did knew the basic structure of the language but a lot of components that could be combined, because of my previous experience in other works.
Also I had some previous knowledge over the required problem domain.
In that case "candidate a" was more effective.
Some years later I was hired as "candidate b" for an application with a lot of knowledge over the arquitecture. But most of hard requirements came from the business logic (the problem domain). And the result was not the same.
Don't trust blindly on the publications. At the end you need working code not theory.
At least that your are hiring an architect...
Def. There has to be some investigation into a candidate and the quality of these extra "leverage points" too.
Trying to figure out what candidates are better can be really hard too.
But overall, putting in the extra work will help you excel.
As you said, sometimes the raw domain knowledge and experience is what counts more. I would expect this in more enterprise type positions though.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.