By custom, all software engineer job postings in the US are required to include the phrase "must thrive in a fast-paced work environment." This is usually not a bona fide qualification, but rather an advertisement ("we're fast paced, so we hope you like that?").

The reasoning is sound: Engineers generally aren't drawn to listings with "must be able to grind through mountains of red tape, bureaucracy, and slow process. We deploy once a quarter." And every tech company thinks it is fast-paced[1] the way every driver thinks s/he is above average.

But what, exactly, does fast paced mean? No, I don't think you can use meter sticks like "we release every (day|week|month)" - or at least, you leave a lot of room for gaming that kind of metric ("I FTP'd a new config into the production server today").

I think there's a reasonable test that is a good proxy for how fast-paced any engineering environment is, phrased as a question: "Say the app has a one character typo in some production code. How long, in the best case, does it take to go from someone in the company knowing about this to it being fixed?"

You can learn a lot about the maturity of an organization with this one question, because you can ask this of a specific engineer on a specific team and they're going to start going down the mental checklist of how to actually deploy changes and then you can have a deep conversation about QA, automation, build times, and deployment process.

You might be surprised about the answers you get!

[1] Conflating 'long hours' with 'fast paced' is 😂