Absolutely, there are many nightmares. I know death march, I've experienced it, but I'll fight for my team never ever to, should I succeed they shouldn't be penalized for not going through the pain. I'm constantly teaching how to be pragmatic while shipping. My nightmare has been integration with external vendors. Testing blind all from unproven specs.

Agree. Even in the best environments with good processes, everyone with a few years' experience will absolutely encounter a case of "something was more difficult than we expected." Being in a good environment just means that more solutions are available (e.g. communicating with management and reducing scope).

Note that the parent post put a lot of emphasis and importance on "death march" specifically, so you are actually altering his/her point quite a lot here:

> I absolutely would not hire an architect who's never done a death march

Oh, I meant that. A candidate for a junior programming job who'd never been on a doomed, nightmare project? Sure, no problem. But an architect? What if something we're working on turns into a death march, for reasons outside of our control?

An architect role isn't just a technical role. It's a leadership role. An architect who cracks under pressure easily is a liability for the entire team. If someone has never had to work when they know they're going to lose, they have no experience with it, and don't know what to do when it happens.

Perhaps, though I'd strongly disagree. However, they phrased the actual interview question as:

> "Can you talk about a project you experienced that went very badly?"

And that question, as phrased, seems quite reasonable to ask any prospective architect. The answer tells you quite a bit about how they handled themselves, how they worked with their team, how they talk about their project and team, and how they diagnosed and addressed the situation.