Instead, you are looking for good co-workers, good management, a comfortable work environment, and a compelling or at least interesting-enough business. You are not looking for a company that merely subscribes to your pet programming philosophy.
If they don't use a bug tracker? If they don't use version control? If they edit the code on the live servers to make changes/add features?
(I've seen all these things)
I agree it depends a little on the specific project but a lot of these kinds of best practice stuff are more than just pet programming philosophies. If you are used to or function best in a place with a certain level of professionalism than working somewhere with some cowboys who just wing it or somewhere were the every piece of work is in a feature branch with a corresponding user story, conforms to a style guide and has proper tests is probably not a good fit.
Where a team falls on this spectrum is part of the company culture.
These are all practices that in a larger team, or with a larger user base, or with higher requirements, would be untenable. But they work for us, for now.
I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests).
To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.
In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.
"Once the code is well-written, I don't think that adding tests would significantly improve my productivity"
Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.
When I ask a question in a job interview, it’s because I want to learn something about the company, because I want to know whether its corporate culture and its philosophy of how to run a software shop are in sync with how I want to work. If significant questions get the “it depends” answer, I take it as a sign that either the place is so chaotic that it doesn’t have a corporate culture, or that I won’t know what culture I will work in until I find out who my manager is.
One of the key signals I use to judge someone's intelligence is their willingness to say "It depends." Because that demonstrates their comfort with ambiguity, their ability to see distinctions in circumstances, and their confidence in being able to make sense of unfamiliar surroundings. All of these are absolutely essential in doing high-level creative work, where there's no roadmap of best practices because nobody's done it before.
It's great that you ask the question, but if you're looking for a specific answer, you're doing it wrong. You should then be able to drill down into "Depends on what?", and then if you can have a sensible conversation based on that, you've probably found someone worth working with.
Or, you know, it means "it depends". Because sometimes, it depends on the circumstance. As they say, the exceptions make the rule.
The larger point here is that if you go into an interview prepared to dump on a company because they're not absolutists about your particular favorite development philosophy, you shouldn't be surprised if you don't get the job. And nearly every company is going to have something that they're letting slack in order to keep the lights on.
So maybe not having unit testing is a deal-breaker for you. If so, fine. Don't work for companies that don't unit test. But I hope your list of deal-breakers is short.
So personally? I say find employers who subscribe to your pet programming philosophy, but don't be willing to rule out someone who doesn't.