This behavior selects for good, or at least compatible, coworkers. Of course if you are desperate for a job then you should read the room and say whatever they want to hear, but if the job market for your skill set is strong, you should show your personality and be open about how you approach technical problems (unless you're really an over-the-top asshole, and nobody thinks that about themselves, so it's pointless to give advice for that situation.)
Once in a technical interview I was asked what data structure I would use for certain functionality "if performance was really critical." I said it would depend on the size and structure of the data that we needed to support, and when the interviewer said "unbounded," I said that the answer to that would go beyond an in-memory data structure, and if performance is critical you need to be able to project the sizes of data you need to support in the near future.
I could tell the interviewer thought my answer was ignorant and sloppy. He started giving me a few "hints," which showed that what he wanted was the data structure had the best big-O performance. So I told what the best big-O performance was for the problem and what common data structure would provide it.
Then he said, "So you would use that?" wanting to put the question to rest and move on the the next one, and I could have said yes. But instead I said "maybe," and I told him I remembered Bjarne Stroustrup talking about how algorithms classes in computer science education give students the wrong idea about how software engineers choose data structures and algorithms in practice. The university version, he said, is that if performance isn't critical, you just pick a container with the right functionality, and then if it turns out that performance matters, you pick something with the best possible big-O characteristics to get ideal performance.
In reality (according to Stroustrup), when performance isn't critical, you should pick something with good big-O performance, and if it turns out that performance matters, you measure on realistic hardware with the data sizes and characteristics you need to support, and in many practical performance-critical cases you will end up choosing something with theoretically suboptimal big-O performance.
I told the interviewer I liked Stroustrup's approach, and I always used data structures with known good performance by default, but I would measure if it mattered. I didn't get the job, and that was probably for the best at that stage in my career. I've nevertheless ended up working in situations like that, where people living by ideas I knew well thought I was an idiot for not understanding them, when I really just didn't completely agree with them, and those situations did not end well.