I've done the equivalent of this by asking them to describe an interesting bug they've encountered in past lives; how it came up, how they hunted it, how they fixed it. By listening to them describe the work, asking questions, and following their thought processes, you can come to a fairly good hire/no from this single walk-through.
I know, it's short and humane, so not a good fit for current Sillycon Valley culture.
I straight up lie and make something up for these "tell me about a time..." type questions
Unless it was literally a week ago, I work on too many things to ever remember anything, and for me it's just a fact of the work that I'll be fixing bugs or whatever the questions asks. Nothing stands out, because I don't consider any of them to be some sort of special occasion worth keeping track of
compare this with the technical interview bomb of demanding you write a full blown program right fuking now, complete with tests. Which one do you prefer?
Live bug squash is better, imo. I was part of the production support at my $DAYJOB. My work was literally finding and squashing bugs all day. And yet, if you were to ask me for interesting stories, I won't be able to tell you anything. Maybe I'll remember the latest bug I solved but most of the time, once the bug is resolved, its off my mind. I will have to go through my jira and github history to first see which bugs I even worked on, then filter for the interesting ones and then try to remember the story instead of just the root cause.
I know, it's short and humane, so not a good fit for current Sillycon Valley culture.