So for about 10 years my main interview question was:

"Write me a function in any language of your choosing, that takes an array of integers and returns the sum."

I loved it. Here is why:

1. I'd get to see them write code, in a low pressure way, but they'd have to write something

2. A shocking number of people would struggle to write the code. That was my signal to end the interview early.

3. I'd get to ask "So tell me how it works" and they'd sometimes look at me like I'm a moron, but others would be respectful and kind, and that would tell me how they'd answer other people who ask questions they felt had obvious answers.

4. I'd ask "what could go wrong at runtime?" - this would be where most people got surprised by their own responses, but it was a fun conversation to have about a seemingly simple function.

5. I'd ask how they would fix any potential runtime exceptions or potential undesirable behaviours

6. I'd try break it, and ask how they would handle that (if i could, i often could)

7. If we got this far, then we could move onto other questions and they're warmed up and generally feeling safe about how the conversation would go. I'd like to switch from coding into data structure related questions normally.

I hate high pressure coding interviews, also, who the hell doesn't just sit there and Google / LLM the answer anyway. The real question I want to know is "How curious are you? Do you want to learn? What kind of person are you? Will I enjoy working with you when things get hard". That's hard to figure out, but you're not going to do that if you just try stump someone in an interview. I think it's on the interviewer to find a way to ask questions that are revealing and accessible in an interview environment...and frankly, I think you get more out of it if you make the effort to keep it simple.