It was bizarre.
This has been a very enlightening practice. To date, almost 100% of the places that showed me code put me off enough that I wouldn't have accepted any offer from them. The way they wrote their code told me more about the deep-rooted problems they had than anything anyone could ever say or not say in an interview.
It was fairly obvious to all concerned that those places and I weren't a good fit, though, and most didn't make me an offer in the end anyway. But if feedback was at all honest, asking to see their code has nothing to do with that, and in fact it was more often taken as a positive sign that I was genuinely interested, which at that stage I was.
My other favourite thing to do is turn questions around. If the people interviewing me at a smaller company are supposedly the senior technical people and they're assessing my abilities during a discussion about a code snippet (mine or theirs) in the interview, then I'm going to assess theirs as well: I will use a certain level of terminology, or mention related concepts, or allude to alternative design possibilities, and watch for their reactions and where the discussion goes. In other words, I would be assessing technical interviewers just the same way that I assess a candidate from the other side of the table, and for much the same reasons.
By the way, you should never feel insulted just because someone asks you to write code at interview, no matter what your level. I used to get some mild irritation from that, but having interviewed supposedly very experienced candidates, I have found that even those with great-looking CVs can be clueless no-hires in practice. The point of the basic coding test isn't to make the really good people stand out, it's to make the really bad people stand out. Of course, if you rapidly produce a decent answer to the simple coding problem, continuing with more simple coding problems starts to say more about the interviewer/company policy than anything else, and you might reasonably question whether they are wasting your time at that point.
And I think I am bad interviewer if I cannot do that.
Do we really TEST Lawyers, Surgeons, Cooks in an interview?
Those occupations are nothing like being a programmer.
We sit them in front of a computer with various editors/IDEs and ask them to code a function/class or two there on the machine.
Isn't this better for the candidate (ie less stressful, interviews are stressful enough already) and more realistic, as they can use editor/IDE features and the compiler?
If someone isn't comfortable with a complete stranger trying to validate whether they are the person described in the résumé, I suggest that they work hard on their networking so that they are always in a situation where the prospective employer is convinced in advance that they are a good hire.
He waved me off, that was good enough for him. The rest of the interview was then about cultural fit and ability to ship software on time without drama.
(And no, what I wrote is not in the same league as Clojure, much less the same ballpark. But it was good enough to demonstrate some basic understanding of Java and familiarity with undergraduate-level Computer Science.)