Of course you could. Just as you could argue that wasting time asking a bunch of questions about hidden requirements for a simple “fizzbuzz” question is indicative of a candidate that prefers talk to action.

Remember, the stated purpose of the question was to filter non-programmers from programmers. If the real purpose is to evaluate a candidate’s proficiency at eliciting hidden requirements, I suggest that there are much better problems to pose.

For example, a design problem that is closer to the actual company’s domain.

You could argue that any interview reflects the organisation doing the interviewing.

For instance, if situations like this one happen often in the organisation, then that might be a negative symbol for the job as it indicates a lack of rigour in gathering and specifying requirements. An interview question like this could prove to be telling, and have a negative impact on hiring.

Likewise if the interview is unfocused and rambling, or the interviewer is looking for a particular answer (not just a working answer), or the interviewer just talks about themselves, etc.

These are all hypotheticals, of course: it's up to the interviewee to determine how likely these are for a particular organisation. It's useful to keep in mind when interviewing, though.

I'd argue back that if we're suddenly in a high stress situation where I need to divine the requirements are, I'd ask what the hell were the project managers, requirements analysts, scrum masters, etc, all doing before this point?