Agreed. Way back when, when I was young and stupid and knew everything, my head was full of logic puzzles and programming tricks. So it was easy to solve them in an interview. But today, there are so many things in my head that I cannot keep them all there at the ready...so I usually dump less important things (like puzzles) out of my brain's fast-retrieval cache, and store them in long term memory.

Also, I work on multiple problems at once so I have to do a slow context-switch, and fill my brain's cache with the working-set of the problem (usually by googling stackoverflow etc.) and then solve it quickly, before dumping the cache.

As I developed more wisdom, I usually don't keep small details in my long-term memory, but only repeated patterns and useful details.

Interview questions are more appropriate for a simpler time when programmers were more single-threaded in their heads. They are also heavily biased towards the programming issues of the 1970s and 1980s...doing all of the things which were left out of the standard libraries...recursion, dynamic programming, sorting algorithms, string parsing, set theory, data structures etc. In my humble opinion interviews should focus on questions of style--take this code, refactor it. Refactor it again given new constraints. Multithread it. Make it secure. Refactor it given that you cannot touch this non-optimal code that someone checked in in a hurry and cannot be removed in a short time frame. Etc.