If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional).

Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too.

But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.