> Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies.
Different problems test for different skills. Perhaps that colleague just misunderstood what he was being tested on.
Linus Torvalds had this to say: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Not every coding challenge is about software design skills. A large number is about the programmer's potential to code to DS & A. It's assumed that design, philosophy and other moot software skills can be picked up, or that internal coding standards and code reviews somewhat mitigate a lack in that area.
But I can very well see a mature engineer being annoyed by someone incessantly asking to confirm small details on a problem where they could make their own decision about terminal and exceptional conditions. Even if they have to explain them later. After you probe your interviewer once or twice on edge cases, you're usually told to assume the simplest situation. This should nudge you to what you're actually being tested on. No need to beat around the bushes, just solve the problem.
Also, to gain insight into the culture of an organization, don't just assume or infer things, like that colleague did. Ask proper questions. Express that working in an organization with a mature engineering culture is a concern of yours. Ask about code review, software development philosophy, etc. You've shown yours, ask them to show theirs.