When I interview candidates and their solution encounters an unexpected condition I typically park the original question to temporarily discuss how to handle this exception.

This and more generally their thoughts on how to handle other types of unexpected scenarios is an important part of delivering real world solutions. I'm shocked by the amount of engineers that don't have any thoughts on this topic.

I saw a tweet regarding it that the IP rate limiting fell over due to X-forwarded-for header not being correctly handled allowing the bypass of that circuit breaker.

My go to question for interviewing candidates is "What trends do you see in web development now or you see being important in the next few years?". There's no right answer there, I'm just looking for something relevant that shows they've got some knowledge of the field outside of being able to bash out code to order. For juniors I don't really expect much while seniors should at least be able to talk a bit about a couple of things, but having interviewed prospective head of development candidates I was amazed that two out of four just tanked on the question, one just couldn't answer at all.

Candidates who know there are things they don't know about I don't mind, but candidates who are unaware of these things at all are typically uninterested in broadening their knowledge, and not someone I'd like on my team.

Can you outline what you might expect in an essay exam for a software engineer position?

Would it take the form of a standard interview question:

"Write a few paragraphs on what happens when you press a key on the keyboard"

Or would it use the medium to ask a question less appropriate in an oral interview process?

Genuinely curious what you envision with this format.

There is plenty of use for coders who can't spot SQL injection issues. I can't think of much use for a coder who can't do fizzbuzz.