For every interviewer who asks how to find if a number is in both arrays and is expecting a detailed discussion of he to do a nicer job by not actually having arrays, there's another interviewer who just wanted to see if the candidate can write two loops, leave the loops early when the value is found, and not run the second loop if the first one doesn't have the value; expecting to do all that in five minutes so more complex questions can be asked.
The fundamental part of the job being that writing code without having a good understanding of the problem is a waste of time and often leads to throwing things away. If an interviewer was annoyed that I asked for more information about a problem before writing any code I'd take that as a sign I wouldn't really fit in at the company.
I was a cofounder at a startup that was trying to improve requirements management for a couple of years. This might go some way to explain my attitude about this. I really hate writing code to solve problems without having enough information first. It's so wasteful.
Yep. You're giving bad interviews because you're expecting someone to have the same previous recent bad experiences as you. I would never ask about the context of the problem you gave because it is so obviously just a quick coding test. You want questions about the requirements, you need to ask a question that feels like a real world problem.
The skill and art of "coding" is in finding solutions to problems, not "writing code". When I interview people I'm looking for someone who can explore problems, ask questions, and find good solutions. If they don't feel like they have enough information I expect them to question things. If they're working on assumptions (like 'what does the array actually look like?') I expect them to question those assumptions. Expecting someone to go deeper in to a problem by finding out more is not "trying to trick them", it's a discovering whether or not they can do a fundamental part of any development job.