A combination of having been fairly lucky and terrible autobiographical memory (I have trouble assembling stories from memories—basically, nothing sticks in my brain as a story and very little from my personal life ever strikes me as story worthy, which made those "what did you do over the Summer?" writing prompts in elementary school absolute hell) mean I have little choice but to pick a real event and invent a narrative for these kinds of questions. I hate them.

[EDIT] remove word that didn't need to be there.

> Uh, maybe they are so good and come from an environment with good process hence no death match.

There are many failure modes other than "death march". I'd be shocked if an architect doesn't have at least one good answer to "talk about a project that went badly". Or, failing that, "almost went badly".

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.

Sometimes you don't have that luxury. What if your company requires an influx of new capital to be able to maintain your current staffing levels and one requirement of the funding is delivering a set of features in a week? Adopting the attitude "we'll just ship a few weeks late" may result in funding not going through, everyone losing their jobs, and the company dissolving.

I agree that death marches are counterproductive. However, if you've been around long enough you've run across situations where they are unfortunately necessary. Another example: production goes down Friday at 5pm. Do you say "we'll pick this up Monday morning"? No... it's all hands on deck to get production back up working as long as it takes, assuming your company isn't large enough to have its own dedicated 24/7 incident response team. Hopefully there's a lot of process and automation which helps to minimize the effort, and if not that's a great takeaway to improving the process down the road.

> Sometimes you don't have that luxury. What if your company requires an influx of new capital to be able to maintain your current staffing levels and one requirement of the funding is delivering a set of features in a week? Adopting the attitude "we'll just ship a few weeks late" may result in funding not going through, everyone losing their jobs, and the company dissolving.

So then the question is actually asking, "have you ever worked at a company that was two weeks away from complete failure and bankruptcy?"

> Another example: production goes down Friday at 5pm.

While highly stressful, this is not what a death march is.

If they've never worked anywhere with poor processes then they're incredibly lucky. Even places with good processes can end up in a situation where these sorts of things are necessary.

> A lot of hard deadlines are made up.

Yes, but not all of them are. A lot of my clients face legislative deadlines that don't take developer comfort or work-life balance into account. We need to help them ship X by January Y. It's rare that overtime happens but it has happened and there's little you can do to get around it when a bill is signed into law mandating you do something in 30 days or the state becomes a litigation target.

I've worked in industries with hard deadlines. My first job was in large-scale academic test scanning. The kids take their test when the calendar says to take the test. And the trucks would show up at our docks with boxes full of tests whether we were ready for them or not. We might have a four month period to do our development, but the production season rolled around and we had to be ready.

The worst death march I was ever on was against a legislative deadline. Oh god, may I never do that again.

Before I started with my current company, there was a legislative deadline that gave an agency 30 days to implement some pretty substantial changes, roughly 60 days of full-time work for the entire team. Apparently the folks writing the bill felt that 60 days was too long and the agency should just figure out how to do it.

This also happened to be during a hiring freeze, so no new contractors, no temp employees, nothing. Current team of half a dozen or so had to drop everything they were doing, switch over to this project and work ~12 hour days six days a week just to deliver a mostly-broken implementation right at the deadline and spend another week and a half at the same schedule fixing bugs and other issues.

It would have been much worse if the timelines were extended, if it was 6 months worth of work to be done in 90 days I think the team probably would have quit. They were mostly contractors so paid hourly, so they got paid for all the work, but that's still a lot of hours for that many weeks in a row.

I have been very lucky not to come across anything like that yet.