When I was preparing for interviews I found that the skill that overlapped between interview puzzles and everyday work was the "head interpreter" as I call it. Typically you end up relying on the IDE and the compiler telling you if what you're writing makes sense or not. Static analysis by the IDE would only tell you if you've made a syntax error, you would need to run a test to tell if what you've written makes logical sense too.

So there's a couple of advantages if you can execute code in your head line by line while storing state as well. You can be slightly faster and more correct while coding yourself and while reviewing the code that others have written. Typically in the latter case you don't have the benefit of the compiler or running tests.

In my anecdotal experience I found an improvement in my "head interpreter" after practising interview questions for a while because typically you're not allowed to execute your code. I can't say if any of the algorithms I learnt and practised helped, but this, in my opinion, made me slightly better at my day job.

Math Olympiad Champion::Great Engineer as Excellent Sentence Diagrammer::Great Writer.

Puzzles are fun, but it's best not to put too much predictive faith in them, because otherwise you're just affirming the consequent. Exceptional individuals are quite likely to be good at puzzles, but you cannot (in my experience) assume that because someone is good at puzzles, they have actual skill in solving real-world problems. I've worked with too many counterexamples.