I'm not even sure we are agreeing or disagreeing anymore. I don't like tricky algorithm questions. Well that's a lie, I like them but I don't think they are appropriate for interviews.
On the other hand, I don't feel like knowing the time/space complexity of data structures you would normally encounter in day to day coding to be "tricky". I wouldn't expect people to know about suffix trees or segment trees for example.
> Writing code is about building robust and scalable things. This involves planning and execution.
I completely agree! But I would argue that's why it's important to know your common data structures because otherwise how can you plan? I do find most interviews awful because of the time pressure which is completely unrealistic. On the other hand, if I'm looking at code my coworker wrote and ask them why they decided to use an array instead of a linked list, I would hope they have an answer.
I don't see any virtue in knowing in-depth complexity analysis of any data structure off the top of your head. Sure, it's probably important to know that random access is faster in a hash map than a linked list, but generally questions are much more algorithmically in-depth. With that said, I know many people that would disagree with me and I think they are categorically wrong. Writing code is about building robust and scalable things. This involves planning and execution. Frankly, I don't think "tricky" algorithmic interview questions address either of those two.
And whatever, obviously to get a six-figure job (as I'm sure most people in this thread have), you need to drink the Kool-aid. But I'm not going to sit here and perpetuate this nonsense. Like I said, I don't even like interviewing people because it's expected of me to find annoying little logic or algorithmic puzzles that some poor guy or girl will struggle to solve.