[ethbr0]

It's the difference between working in a push vs a pull shop.

In a push shop (e.g. most non-tech businesses / legacy tech), one is forbidden from working on a thing without management signing off on it and pushing the task to you.

In a pull shop, management communicates priorities (increase reliability) and engineering teams pull tasks to fulfill that.

Believe parent is talking about the former, which is always a cluster&#+@ of technically clueless middle management.

[yaml-ops-guy]

I like that dichotomy. If you or anyone else reading this have any thoughts on it, what are some good questions I ought to be asking during interviews to determine what kind of shop I'm talking to might be?

That's been a real struggle lately, and I want to get better at this to avoid these kinds of push shops you're describing

[ethbr0]

IMHE, people who work in push shops typically don't realize there's an alternative, which makes identifying them somewhat difficult.

On a side note, I've found push shops tend to be highly correlated with length of position (i.e. "What's the longest someone has ever been on this specific team without transferring or pursuing new opportunities?"). But that's probably more accurately identifying heavily regulated industries, which tend to be push shops do to the Byzantine sign-offs required.

I would say don't ask, "Tell me about a time your team originated an idea, took it to production, and the net impact." Because even push shops have the odd exception that can be rattled off. It's more talking about the typical workflow.

The best I could probably come up with is "Take me through a normal task for your team, from idea origination to prod deployment."

If they start with "We were told to do X", then "By whom? And what did they tell you?" (To the latter, did they specify exactly how or just the end goal?)