"In real life, the people whose decisions matter a) often can't read code and b) almost always have better uses of their time than reading code from someone who is, statistically, not likely to be hired."

The person who can't read code shouldn't be deciding the technical merits of a candidate. If that's happening, your hiring process is broken.

Furthermore, your hiring process should be designed such that you can weed out the majority long before the in-person interview occurs. Steps in the hiring process should be scheduled such that the more time consuming parts come later.

I google any candidate who has made it to an actual in-person interview. If they have a github page, I look inside to see what they've done. It helps tremendously if the candidate tells me which projects they are most proud of. What's nice about this approach is it gives us something to talk about that the candidate is passionate about.

It's only when the candidate has nothing to show off that things move towards a more "traditional" interview, with dry coding and design questions.