I've failed in interviews for not using coding magic tricks. I use these tricks and puzzles as an opportunity to ask them about their processes in general and software development practices in particular. Got one job out of that "failure" but the rest I did it just to burn out brightly. Hearing a would-be future manager justify XOR and other tricks as production level code is always enlightening.
So to restate: Every piece of code they show you is an example of their production code and philosophy. They are deliberately showing you what they consider the best or worst. Judge them on it.
You are interviewing and testing them as much as they are testing you. A lot of interviewers fail to understand this.
Postscript: this is from a history of interviews and followup from accepted positions across multiple organisations. Every puzzler-heavy interview job I have foolishly accepted later ended up in management misadventures, culture defects or political issues. The interviews without the foolish puzzles have been indicators of future success. For me there is a clear correlation.
This is a super basic example, but I had a phone-screen question that was "reverse the order of the words in this C array in-place without allocating more memory." I found out with clarifying questions that I could use a temporary variable, but midway through I remembered how the XOR swap worked, and I think that scored me some points with the interviewer.
Then, if interviewers have a clue, you should almost never see it in interviews.
But do interviewers have a clue? Aye, there's the rub. I have never seen it, but that's not saying much...