I can attest to this fact, as part of a unicorn upstart with dev offices in Sao Paulo and Berlin. Clojure onboarding has never been a major roadblock for new engineers. And we never hire asking for "X years of lang experience". Almost everyone in the (~300 strong) engineering team started with zero-to-little Clojure background.
(It's fine if your work sample test really just focuses on one language! But then make it part of the rubric if that's the answer you want, and tell the applicant about that rubric.)
I can see 1. being pretty easy to suss out (paid take home coding assignment is how I'd do it).
How do you assess 2.?
Also, we encourage our candidates to choose Clojure for their take-home assignment, even if they do not have any prior taste of it. This, for those of them who choose that option, gives an idea of if they would enjoy working in it. Our rubric however does not have a bias against developers who do not choose Clojure for their assignments, and we make this explicit to the candidates as well.
For every one shop that looks at darling niche stuff and thinks, "Ooh, that probably makes him or her a better programmer", there's ten shops who look at it and think, "They're probably going to be insufferable to work with, undermine the architects at every turn, and spend their whole time complaining about the tools we use".
As an aside, if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one. Spring is a portfolio of libraries, stretching across over a dozen business application development domains, with inversion of control as the only common thread. NO language has all that baked into its standard library, and you'd have to pull down a bajillion NPM packages (or whatever) to even come close to approximating it.
Let's please avoid personal attacks if at all possible. Spring started out with the dependency injection framework and "aspect-oriented programming". It was marketed as an alternative to EJB. Web frameworks and other add-ons came later. If you don't see DI and AspectJ as working around Java's weaknesses, then I encourage you to try a more expressive language.
In an expressive language (e.g. Clojure or Haskell), DI and AspectJ could be, for example, replaced by reifying a program as data and using modular interpreters. One interpreter using mock data, another talks to the database, uses transaction boundaries and logs. This sort of solution is unfortunately just not very practical in Java.
In another expressive language like Common Lisp, it has generic functions which 1) let you dispatch on more than just the class type of the first argument (implicitly in Java, explicitly 'self' in Python) which is a feature that by itself removes a lot of Java back-bending and 2) you can specify :before and :after and :around methods to provide the benefits of aspects with the built-in function compute-applicable-methods available to help see everything that might apply when invoking a method with specific arguments. There's also metaclasses which open other doors. There's just a whole lot of built-in expressiveness in the languages beyond the Java and JavaScript ecosystems.
I've been happily employed (and regularly solicited) as a Clojure developer for over 8 years.
There's no shortage of Clojure dev positions for developers that want to write Clojure.
I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. It tends to be highly dehumanizing environment where devs have no say, no autonomy, and no ownership. This naturally pushes out people who have options, and you end up with a pool of devs who just want any job that pays the bills.
Its mostly approach to any work in general. If it were upto them, these are really the kind of the people who would dig earth with spoons and shovels, instead of heavy machinery.
The idea is simple, should you use Spring + Java, you are likely to need say 60+ people to run a product well. It could take 15 to make it work in Clojure. But having 60 people has its own advantages from their perspective. Say 10 people decide to leave, they can hire 10 replacements for the lowest prices from the market, train them on the application and get it going. Eventually the whole team could leave and get replaced this way, reducing the problem to a bit like the Ship of Theseus paradox. But it works for them.
If they use Clojure, they have to treat people well, pay them well to retain them. Because there teams tend to be small and a exodus puts everything at risk.
They have to use spoons and shovels, personnel trained to work on heavy machinery are expensive, training is expensive and replacing them is expensive.
I'm a Software Engineer, and while I have my go-to tools, I'd like to think I make an informed choice to use what fits the task at hand .
An Engineer who's a comfortable polygot is perhaps also a better Engineer overall.
It is the usual "Jack of all trades, master of none." consulting, but it does come in handy when we need to deal with mixed stacks end-to-end.
Optimizing for new volunteer contributors goes beyond core language choice anyway. For an interesting description of how the game Battle for Wesnoth tried to do it, see: http://aosabook.org/en/wesnoth.html
On the more meta level it's weird what people expect devs to learn on the job or know up front. Companies expect employees to keep up with the latest nonsense in web dev, but can't pick up a new straightforward language? Unless maybe another Algol like Go or TypeScript? This Steve Yegge quote captures some of it:
"For some reason, programmers love to learn new stuff, as long as it's not syntax."