Because they aren't familiar with or enthusiastic about the code I give them, they could be about code they have written. It's the classic "describe one time you did something poorly/well"-question, but with code. I want to see them critique some code, or explain what's so great, or why it ended up the way it is.
Reasoning about a problem i have (even showing some code) is also a good part of an interview. But it's my side of the field. I just found it's much better to move the interview to the interviewee's side of the turf, because they are more comfortable there.
For all this thread solution is simple. Small take home assignment where you write the code to discuss during the interview.
I know people are vocal about not wanting to do take homes. But if take home is reasonable and used as a talking piece it checks all the boxes for good tool.
I think in reality I had single person that outright refused and of course bunch of people who didn’t bother to deliver - great candidates delivered it the same day, busy great candidates delivered it over the weekend.
Reasoning about a problem i have (even showing some code) is also a good part of an interview. But it's my side of the field. I just found it's much better to move the interview to the interviewee's side of the turf, because they are more comfortable there.