This is pretty silly thing to watch out for. Being a zealot about anything, especially something like unit tests, is certainly not a good idea when searching for a good job. Setting aside the fact that whether unit tests exist and how they are managed often does depend on the project/product/client (and the fact that many good web start-ups don't do unit testing for very good reasons), it's just a bad idea to discount a company based on some technical aspects you may disagree with (especially if you only have a few years of experience and really don't have a strong foundation for evaluating this).
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.
So where is the line (for you) between not following a pet programming philosophy and incompetence?
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.
When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still regularly edit the code on live servers for some bug fixes. The first two were (barely) workable for a one person team and got fixed once the team grew, and the third is honestly the right approach for the kind of software we write. The user base for most of our products numbers in the dozens, and I'd rather get a prod bug fix out there as soon as possible rather than having to mess with commit;cd $prod_dir;pull -u or having to deal with the complexity of having too many code environments. I have not yet succeeded at getting a proper testing framework in place - too much hassle dealing with selenium and we don't yet have enough tests written to justify spending more effort. It's the initial capital investment that'll make it worth it, but I just haven't gotten around to it. Rather work on building an actual product that'll add direct value rather than just saving my ass.
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've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time.
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.
At this point, I'm not convinced that not testing necessarily leads to laziness.
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.
I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained.
"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.
Unit tests was just an example. The issue is deeper than that.
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.
But that's the case at any organization of non-trivial (> about 10 people) size. You can't enforce uniformity - if you do, you end up with a sicker system than if you'd just let everyone do the wrong thing.
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.
In the cases I’m thinking of, “depends on what?” was met with more vagueness, or, in one case, “depends on what the client wants”. (This was at one of those companies whose business model involves a very small core product and a lot of per-customer consulting work to enhance it. Which is a perfectly respectable way to run a company, but the core-to-consulting ratio was too low for my taste.)
"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."
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.
These kinds of conflicts cause more problems than you might suspect. I respect the fact that different people and organizations code differently. But that respect has to go both ways. Otherwise, you find yourself in a situation where you adapt to others' style of doing things, and they are doing nothing to adapt to yours.
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.
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.