I disagree. The goal of this question is to see how you utilize domain experts as a resource, add your software expertise, and design a comprehensive solution. It is specifically not a question about what you already know.

In the interview I play the domain expert.

This is exactly what your job will look like: collaborate with domain experts, use your software skills, solve real world problems.

I don’t need an engineer who can build a queue. I need an engineer who can use a queue.

Properly testing for a "solution engineer" (which is what you appear to be testing for) would pose a question that is a legitimate "software" problem and "domain experts" would be in areas such as say "electronic payments". Candidate would be expected to demonstrate ability to devise proposals for a 'functional solution to a business requirement' using available domain experts.

The key phrase is yours: "real world problems". Your hypothetical misses that by a generous mile.

And I apologize about this but we're discussing actual issues with software recruitment:

One major problem noted by senior engineers subject to these interviews is the competence level of the interviewer. I had this one guy, a "principal engineer", ask me about "Optimistic locks" as his initial query into my knowledge of concurrent systems. It took a lot of self-restraint to not blurt out "You mean optimistic locking?"

It is amazing to me that we somehow managed to hire very good software workers in the 90s without any of these shenanigans. One thing that does stand out from my memory of the 90s: we had senior colleagues (with literal white hair) in senior engineering positions. Go figure.

Have you considered asking questions that involve queues.

I think you are doing it right.