Perhaps I am approaching the problem incorrectly and the more important quality is attitude and ability to absorb new skills.

This would be my inclination. I would perhaps broaden it to some other factors, but I'd keep it at this higher level, rather than focussing too much on specific technical competencies like "can write a join in SQL".

Unless you have a very specific need for somebody who's ready to hit the ground running on an urgent SQL-joining project, looking at a specific narrow competency like this may not be a great indicator of overall capability. As noted in Makoto's answer, there are a great many data science languages/tools out there; just because somebody hasn't worked with SQL yet doesn't mean they're incapable of picking it up, and just because they've spent the last ten years working on a SQL project doesn't mean they're going to be great at anything else.

An approach that I've found effective for data science interviewing is to present candidates with an open-ended, language-agnostic scenario and get them to talk about how they would approach it, leaving it broad enough that any DS candidate ought to have some relevant ideas, while making it just specific enough that it's unlikely to be completely covered by a generic answer. For instance, here's a question that we used last time I was doing DS recruitment. (NB this was not an entry-level position, so we were a bit more demanding than you would want to be, but the general approach should translate.)

Computing: The purpose of this question is to test your knowledge of computing techniques that may be relevant for data science work. We're not assuming any specific programming language but you're welcome to discuss how different languages might affect this scenario.

Several years ago, [our org] implemented a new mathematical method for producing key economic estimates that runs on internally developed software. Recently, the amount of input data available for these estimates has greatly increased, and the run-time has become unacceptably long. You have been asked to find ways to speed up the software. You can rewrite the software as needed or transfer it to a different environment, but you can't change the underlying method - the results produced must be 100% consistent with the old version.

What options would you explore to improve the run-time of the software?

There are many different ways this could be answered, depending on the candidate's background, and I wouldn't expect any one candidate to cover all the options. But "how make computer go faster?" is a perennial data science problem and any good candidate ought to be have something to say here.

Once they've made some suggestions, we can then dig further in those areas to explore their competency further. For instance, if a candidate mentions changing language, I might ask them to explain why they expect Language X to be more efficient than Language Y, or about what the risks are in changing languages and how they could be mitigated. Effectively, we're starting by identifying where their existing experience lies, and then exploring how they can show competence within that experience, rather than testing on one or two specific points of knowledge.

The "must be 100% consistent with the old version" requirement is here because we don't just want candidates who know a bunch of different methods; we want candidates who can think critically about which of those methods is appropriate for the problem at hand. For instance, we had some candidates who suggested changing the estimation method; this might have solved the speed problem, but it didn't fit the problem requirements.

In addition to this question, we also had one that was a bit more on the data science side - here is a situation with an information need, these are the sources that are available, talk us through how you would approach this. I don't have a copy of the question text handy, but it was the same kind of strategy: pick something broad enough that any good candidate will have something to say about it, then based on their initial answers dig further.