Maybe it's an opportunity to introduce automated testing.
I've worked at many companies where my managers wouldn't allot any time to develop automated tests and change the deployment to accommodate them.
Many companies are just not aware, because they never hired the people who are familiar with automated testing.
Established shops mean established culture. If it doesn't already exist, and you aren't in a position of sufficient authority to make it happen without buy-in, this "opportunity" is probably more likely to be bailing out the ocean.
I've been at a company with thousands of developers, where a guy that was just hired came in, saw a need for a tool that had been missing, prototyped something, and showed how useful it could be.
When there are missing needs like this, it's a tremendous opportunity for someone who is sufficiently motivated.
Of course, there's a balance between a good company that is just missing some things here and there, and a very bad company that is missing just about everything...
There's a significant difference in difficulty between building a tool and institutionalizing a labor-intensive (though very valuable) process. And given the surplus of developer jobs out there, it's probably easier, and better, to just move on to your next option.
I work at a relatively large technology company (Bloomberg) and I have had great success in changing developer culture for the better. It takes a lot of elbow grease, many meetings and you need the gumption to ride through it but we've truly made the day-to-day productivity enhancements that we need for our business. In just this year my team has accomplished:
> GitHub Enterprise deployment;
> Massive project conversions from Ruby 1.8.7 to 1.9.3;
> Adoption and training of AngularJS building reusable directives;
> Utilizing Boxen to make developer work environments reproducible and deterministic;
> Consolidating build systems (Jenkins) and integration with corporate internal systems;
We're really on a roll and I think once you gain the trust of management and they see the moral changing for the better you can really stop the world. But coming in from the outside I can see how this is intimidating and, roughly speaking, you need to consider most organizations are not going to give you the keys to the castle with merely blind faith. You need to disrupt a bit.
I've been there, man; I'm not exactly saying something I haven't tried. :-)
"Intimidating" isn't the right word, though. "Vastly unlikely" is probably closer to where I'm standing. Unlikely to the point where the downside risk--being stuck at a job with regressive coworkers and management who doesn't want to change anything--probably outweighs, for most people on HN, the potential upside given that they probably have other options.
I could go in and risk my time and my earning potential to change things somewhere, or I could go to the next place with their head on straight.
But maybe that's just me, I would always prefer to work at the place that isn't 100% perfect but will give me the opportunity to change things. Much more of challenge in that than just being a replacement cog in an already perfectly tuned machine.
Culture is a lot harder to change than code. If the people already there don't see the value in process improvement, then attempting to introduce any sort of process improvement will be a Sisyphean task. You'll make progress only to see it get rolled back time and again by teammates who just don't believe in what you're doing.
Take automated tests as an example. I have worked at a place where I committed automated tests and configured them to run before build. Then, I got a bug report for a module I had worked on and wrote a test suite for. The test suite should have caught the bug... had it not been disabled by another developer who'd committed the breaking change and, instead of investigating why the test failed, just dropped @ignore annotations until the tests passed again. That's the sort of thing that OP is warning against. Life isn't long enough to spend time bashing your head into walls like that.
The lack of testing culture, for example, was what first drove me away from PHP (to Ruby). Every PHP role interview, I'd gingerly have to ask if they knew what Automated Testing was ("Yes? Great. Have you done any yet? ... No? You don't want to? Oh."), whereas at every interview for a Ruby role I've basically gotten a "Of course we're testing. What else would you be doing?" response.
Once you get past talking about things up to the baseline, you can start the real interview.
Sure, but this is why you ask a follow up question, "why don't you have tests?"
If the answer is "We are just starting this project, and haven't done any yet. We'd like you to help us write tests", then that's an oppertunity.
If the answer is "Tests don't work, they're useless and never catch serious bugs. Our team is smart enough to not break things, and we have to move too fast to waste time write silly little unittests for everything", then there's no oppertunity here.