Precisely this. That's one of the key things from our "experience" and "seniority". We've seen things, we know how to be pragmatic and learn/relearn X to finish Y and deliver value.
I'm yet to see an interview that covers this. I'm clinging to my current job because I'm not sure I can face the job market in my current age.
Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer.
Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.
Yet, if the string of interviews is too long (and it is) the probability of hitting a "reef" is really big. And it seems that either you get a unanimous "yes" or you fail.