My favorite to ask is:
"Tell me about a time you really screwed something up."
This can be a design decision, or may accidentally running "drop table users"...
This is an open ended question. The more experienced interviewees will pivot to how they learned something from it or whatever. I'm just looking for general humility tbh.
If they're nervous or confused, I'll share a few of my stories, like the time I really did drop that users table, or tripped over a power chord in a data center when disaster recovery testing was being done.
Warning signals in responses could be someone claiming they've never failed at anything, or trying to push all the blame onto former colleagues without owning any part of it, or when asked what they'd do differently in a similar situation in future, saying that they'd do exactly the same thing.
All that said, I'm not sure this kind of question adds that much value to an interview pipeline. Many candidates early in their career may not yet have war stories of how they broke production, or may have poor interview technique and not really know how to handle this well. Arguably asking this question is putting someone under pressure in the stressful context of an interview, to see how they respond. People who are already terrified by the interview process may not respond very well at all -- but how relevant is this to the role you're hiring for?
This question might give you a strong red flag to reject a candidate < 5% of the time, but it doesn't give you a reason to accept them. They still have to do well on the other parts of the hiring process that assess technical skills & problem solving.
How big of a fuck up are you looking for?
Do you wanna hear about the time I broke all internet e-mail for the entire world in 1996, or do you want something more recent?
Hen you ask an intro question like that, I think you would want to have some idea of how you'd answer my questions like this.
Which is not to say that there aren't people who simply don't care about the env they work in, yet are great SWEs: it's just that it reveals the persons attitude, preferences and can get them excited (for better and for worse :)).
Along the way I ask a few questions about bits, which provides some dynamic signal (for example, would this person be good at low-level stuff?)
I'd expect anyone who knows how to code in anything to understand the concept of an associative array, but not necessarily the nuances of hashing and performance, especially not the performance of specific hashing algos. Most of that work is handled by language designers/compiler designers for you in the majority of use cases.
I suspect you work in a field where this sort of information is far more well known/common to deal with in day to day?
I think a similar interesting question: asking for one or several things the applicant dislikes most about the programming language, would be similarly revealing.
YMMV when it comes to people who are smart but not very good talkers, but I think it's better than, say, asking people to sing a song, like some recruiters do.