Basically I ask some questions where the requirements are ambiguous, and the solution is non-standard. Other times I ask someone to write a simple task using an outdated API.

Why? Someone who can't figure out the ambiguous requirements will require a lot of handholding. I don't have time for that.

Someone who argues about the requirement to use an outdated API either doesn't get the point of the question, or will ask to refactor years of perfectly working code on the first day. The outdated outdated API goes through so many core concepts that it's an awesome interview question. Someone competent should move through it without any struggle!

Even worse is when I ask someone to write some manual SQL and they tell me that doing SQL by hand is outdated! Instant rejection! I want to know that you understand the underlying concept without relying on magic. Manual SQL is easy, if you're competent.

Or, I had someone tell me that passing values to a constructor in C# is outdated... Not when you're using immutables for thread safety!

That's what I mean by play along and tell the interviewer what they want to hear.

That sounds reasonable enough. My last experience was more of a total non-adjustment to the actual candidate.

E.g. asking such bullshit vague questions that might work on a recent graduate because you could assume that's a software engineering 101 question but if you actually asked them what exactly they meant, even just the scope or language, or offering 3 different paths of which one you'd like to sketch out tot hem .. blank stare, repeating the question.