In interviews I've never forced anyone to code, what I do is try to get them to tell me these sorts of war stories - I want to hear how you fixed it, why it was cooly bizarre, and I'm hoping for some enthusiasm when you talk about it.
I couldn't always get people to talk this way, but people who did usually worked out well
This, whenever I get these sorts of questions on interviews I don't know how to answer, because my weirdest or hardest bug isn't something I've internalized as a war story, it was just another day.
It's just like those "what did you do when you had conflict with another employee" questions. I either worked it out with them like an adult or got our management involved and they worked it out for them. It's not some hero narrative I considered much past the time it happened.
No, they're selecting for the kind of person who can tell a war story when asked. They're also selecting for the kind of people who had to debug something gnarly enough and different enough that it was memorable.
Some people are not natural story tellers. Telling a story is not a usual part of the job responsibility of a software engineer—we aren't novelists. Having a memorable debugging experience doesn't directly equate to having a good story to tell.
This is really the same issue with the promo culture we see at Big Tech companies: you end up promoting the people who are good at crafting promo packets i.e. telling stories about their work. There is certainly a good overlap between that and the people who do genuinely good work, but it's not a perfect overlap.
Personally I don't really mind it because I consider myself good at story telling. But as an interviewer I would never do that to a candidate because not everyone can tell good stories.
I couldn't always get people to talk this way, but people who did usually worked out well