A dark red flag? That's like saying you wouldn't hire someone because they use different code style than you, you can't just ask them to follow your company's style instead? To me it just sounds more like you're taking people's style decisions personally, and refusing to hire anyone that doesn't think the same way as you. That's a big red flag to me as anyone that would want to work there. You're trying to say infinitevly that crashing is bad style, but it isn't.I recommend to rethink this. I do quite some interviewing these days and saying something like this in an phone screen or interview would be a dark red flag. I don't know what experience you have in professional development, but maybe don't think so much shipping, but daily development in large teams of maybe 100 people. If you crash loud and hard on every little bug because of not programming defensively I don't see such a team working effectively.
There are two ends to this point, one is to avoid crashing at all costs. This introduces bugs frequently, it keeps them around longer, possibly forever, it flat out lowers the quality of the software. On the other end we have crashing all the time, it gets the most bugs fixed but scares people more because in theory it might crash at an inopportune time and embarass people or cause frustration.
To me that says a very simple thing: it depends. It depends on the environment, the type of software, and who is working on it. If I'm working on my own game by myself i'm probably more likely to just make everything explode if it fails, that helps me find bugs fast, and I lose nothing from it crashing. In a big team environment it depends on what you're making, a tool crashing is more annoying than a game crashing. A game crashing is only bad really infront of customers. There isn't a one size fits all solution here.