Well, when we recruit a Python dev, we do ask a few skill based stuff (most of them are bullshit detectors, then some question to gauge how they follow the trends, and are able to give correct answers about the main diff between Python 2.7 and 3.x, which interesting new thing you get in 3.x, 3.5, 3.6, 3.7. Having the right answers is not mandatory, but help gauge how much the candidate is up to date and follows the updates. Then most of the interview is usually about problem solving, analysis, and things like that. We use Flask and not Django, but I hardly care if they know one and not the other one.
A skilled developer can learn a new framework/lib very quickly.
But it takes much longer time to teach problem solving, analytics, being autonomous, being a good communicator. So that’s what we try to evaluate during the interviews.
We do code tests, but I am really thinking of replacing (or completing) that with a code review test... I hesitate for way too long and this would give us ideas about the bad and good practices the candidate has, how he communicates these ideas, ...
All to say that this list is nice from a skills standpoint, but that’s just a fraction of what could make a candidate a great fit (or not) in a team. As a company, part of this would be nice, and we really don’t care about other items (and I assume this changes from domain to domain. For instance Spark, numpy, scipy, pytorch and co could either be required or not at all depending on the domain/role.
So yes, for someone trying to grow his t-shape and expand his knowledge, that could give some ideas. But doing an average of 300 job specs for different roles in different domains just gives a jack-of-all-trades which is neither the ideal teammate you’re looking for nor the ideal next hire for your team ;-)