Don't work for companies like that. I have a few "red flags" which I look for when I interview for companies to avoid this type of mindset and if I see enough red flags I reject the company.

Those places are usually career dead ends anyway, even if you're not bothered about working remotely.

Unfortunately, there are many places which only have employers like that which means you either move or you deal with it.

Can you elaborate on what you're looking for at the interview stage to determine a company has this mindset? I've seen it after a few weeks at an org but figuring that out earlier would be helpful.

I have a few questions I ask which often tease out the red flags:

* What hours did you and your team work in the last month? (anything that indicates long hours are frequent is a red flag, not because long hours are intrinsically bad (though they are), but because it's usually being used as a proxy for measuring productivity).

* What is your policy on remote working? Who do you have remote working currently and under what circumstances? ("no remote working" is ok for me if there's a non-bullshit reason but YMMV).

* Who is currently your best or one of your better developers? How did you come to that conclusion?

* What characteristics do you look for in clean code vs. technical debt-laden code? How do you handle and plan for paying down technical debt?

* Who reads your team's pull requests? (worst answer is "nobody", 2nd worst answer is "the team").

* Have you read any of my code? What did you think?

I'm usually not looking for a perfect answer to all of these questions, just avoiding the companies that give an impression of widespread systemic dysfunction in their answers or a manager who is clueless.

These are actually quite good.

I never thought about teasing the red flags, but it makes more sense than just asking directly.

You could publish a list somewhere, I think a lot of people would find these valuable.

How did they work for you in practice?

Best/worst reactions to them?

>>> * Who reads your team's pull requests? (worst answer is "nobody", 2nd worst answer is "the team").

What's the best answer you've heard for this one?

Something involving not only the team reviewing each other's code but somebody with the power to hire/fire (i.e. the answer "I will").

Ah, makes sense. Thanks.

Echoing dandandan. Would you mind sharing these red flags?

Um. That sounds really stupid advice. Software engineering is not like logging. Not if you want to run it profitably. I don't think any manager actually worth her salt will actually heed to such an advice. Younger, more insecure managers - they're better off practicing the crafr of management with onsite personnels. If some company that has an umbrella no-remote policy - well, just work elsewhere.

The team is more important than any individual, but each member of that team is indispensible. The team becomes the way it is not in a vacuum, not because of the company, or culture, or manager (though those contribute), but do to each individual on the team and what they bring. Kind of silly to think otherwise...

This seems... odd to me.

Teams are composed of individuals, and we've set up things so that if the team doesn't depend on the knowledge of one individual. However, we still have people working remotely and the engineers are valued because they create value, not because they hoard knowledge.

This is true in some organizations, but it can depend on the culture and assumptions that people have about remote working. There are many companies that are bought into having people all in the same place because it helps with "velocity", or whatever management are into at the time. The irony is that many companies producing collaboration tools to support remote work software fall into this category of employer.