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

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?