I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions.
If this were a heuristic of a good developer, it would let me (not a dev) in and who knows what the effects of that could be :).
I suspect people like you, genuinely good at reading code but not at writing it, are not a significant threat to the average dev hiring pipeline. There aren't that many of you and you have better things to do than apply to programming jobs you're not qualified for.
You might be overestimating the grade of people who make it through coding interviews.
I'd rather hire-- as a coder-- someone that could read code but would fail an interview where they coded, than someone who could pass some trivial coding interview but couldn't read code.
Obviously, people need to do both, but the reading seems less likely to get a false positive/negative in an interview.
Heck, given two candidates one who cannot currently code but reads code fluently vs one who can code (and not just pass a coding interview) but cannot read code-- I'd still prefer the reader. It's the more important skill.
Average industrial programmer is going to write 8 lines of code per day. If you can correctly read a codebase, you can probably manage to write 8 working lines of code per day for it on average. Maybe you wouldn't be #1 one the team overnight, but a fluent reader is at least on track to be average even if they hardly write at all now.
Oh Writing Code is easy: copy and modify ;)
Pros remove the edge cases that allow exploits from stackoverflow examples, but you seem to be qualified to do that.
I think one way to iterate on this to weed out guys like me would be to ask process based questions that reveal the candidates experience and preferences:
“Brainstorm with us on how you would you make this messyFunction more performant given $these conditions”
“We are thinking of developing a feature that would call this function more often. Would you turn this into a micro service?”
“Looking at this db call, how do you see this scaling if we increase the number of x and y?”
If this were a heuristic of a good developer, it would let me (not a dev) in and who knows what the effects of that could be :).