What we have found is that it is enough to verify 'can get stuff done', and leave out 'in the language we use'. So, much of the interview turns out to be a process of validating two things:
1. can do what is claimed in the language of choice.
2. gauge enthusiasm and interest to pick up our language.
FWIW, that's been our experience as well (both at a largeish publicly traded company and now at a small private consultancy). Go get work sample tests :)
(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.)
Mostly in our conversations, in an informal way. I would say the assumption we make is that developers with a penchant for any form of functional prog and/or Lisps, and with an acute focus on testing have an easy time grasping Clojure. And we bias our rubric towards this.
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.
