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.

The popular way of quizing developers during the interview has more about throwaway leetcode than experience.

What you're digging for is about their experience. To me, what you're finding comes at no shock. The industry has been punishing people with experience and willing to show it for years.

I think it depends on level you're interviewing at. New college hires rarely have much a clue about this but engineers and senior engineers should be able to have a conversation about it. To be fair because of time constraint, I don't have candidates code this but do want to entertain the discussion. For example, what happens if i pass "illegalValue" to your method, or what do you think your solution should do when the service dependency you call fails to return.

The sentiment is important because it shows how a candidate ties the requirements to the customer use case that it is serving. Not being able to connect these two is a concern in my mind especially for those who are not new college hires with little real world experiemnce.

It is an important part of delivering real world solutions. How often is it a part of being hired to deliver real world solutions?

I'm not sure I understand the question. In my mind, if you cannot reason through how to handle non-expected things in your code, I'm going to think twice about hiring you. Code being able to account for erroneous situations is as important as your golden path because as we know software should be predictable but regularly is not. Especially so in the world of micro-services where so many integration paths are changing and in flux.

Are you suggesting we should only interview candidates to code the happy case and not consider how they will reason through what to do when the input isn't what they expected or a dependency fails to produce results?

I think you should hire for that skill.

In practice, I do not think candidates are hired for that skill. I have never been asked about error handling in an interview.

Generalizing things because you've never experienced them on an individual level seems like a bit of a stretch. Anyway, it may not be asked in interviews but I've interviewed ~300 engineers for a FAANG company and its something I cover in interviews for the reasons described.

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.