I've found you can somewhat mitigate it by asking questions yourself. For example in one tech screen once I had the algorithm pretty much done I asked if I should look to optimize and to add test cases/handle odd input and the interviewer said it's fine as is and let's talk more about other topics like architecture in the real world.

Absolutely, that's something I pointed out in my writing: if the interviewer doesn't explain their expectations, you can and should ask. Interviews work best when both parties are engaged heavily in the success of the interview.

On the other hand, I go through months where half my job is devising ways to extract requirements from users who just want me to "make this problem go away"! I consider it very reasonable to test someone's ability to work out what problem they're meant to be solving.

You know what your job is: to figure out the problem. And the interviewer should be clear they are looking for you to figure out the problem to solve.

I'll keep these in mind.

I like to ask open-ended questions. "I am trying to solve X problem, how should-I do it?". That reduces the rote bias and also checks if the candidate can communicate.