Would you accept a job offer from a company that wasn't writing unit tests?

There could be many reasons why the company doesn't write unit tests, and some reasons may actually be sound. When this situation arises in an interview (or if you find out before the interview), it's best to ask the interviewer why they don't write unit tests. When you do this, remember 2 things:

1. You can't ask them in a tone that indicates judgement. They may have a reason and, if you ask it in a way that makes them feel stupid, you're not going to get a good answer (and maybe fail the interview).

2. You should prepare for a follow-up question from the interviewer about why it would be beneficial to write unit tests. If you can word it succinctly (in both technical and business language), you may just win the interview right there.

In 15 years of programming, I've rarely seen development teams have a full test suite for their applications. Most of the time I see applications with the barest of unit tests, that just cover the happy-day scenarios (but never negative test cases). Some other applications have 0 (yes, 0!) unit tests, but those tend to arise from another team writing the software in "Agile"* and then handing the finishing software to another development team to maintain. In one, rare, instance I even had a manager say that writing unit tests aren't required because it will only prove that the application works, which is what the QA team's report tells him.

Thankfully you are young enough to be trained in TDD and such, and may be able to show that unit tests can reduce the risk of the project when code changes happen. That type of information is invaluable to a manager.

tl;dr: Be open and curious about why the company doesn't write unit tests, and you may find out how real-world development teams work.

* I put Agile in quotes because this particular team said they were doing Agile programming, but in reality they were able to quickly produce deliverables only by cutting corners by not producing documentation and tests.

Sure. Even more so, I'd accept a job from a company that doesn't idolize BS like TDD, and knows that tests have their proper place.

Stick to TDD. It will make your life easier.

Sure..

Hell, I have accepted jobs where the programmer had left and nobody even knew what language they were using or really anything at all about what the previous programmer had done..

call me crazy..I called it a blank slate...

If it's a great company what's the problem? There's an opportunity there for you to add something/teach them something almost right away. It's relatively easy to setup a framework and and everyone will appreciate what you've done. You can even integrate it into their continuous integration as well.

Since Pinterest doesn't write unit tests, and I'd take an offer to work from them, yes, I would.

Depends on the company.

I have around 20 years experience as a developer, and contrary to the hype you seen in many conferences, truth is very few companies do unit tests, specially if they are quite big.

One of my tasks in our consultancy projects is to teach companies why they should invest in unit tests.

The vast majority of companies do minimal or no unit tests. My estimate would be less than 1% do significant unit tests.

If a company doesn't do some sort of automated integration tests, that would probably be a much bigger red flag, as for any sufficiently complex software, what works is approximately equal to what is tested, and automated tests let you test a lot more than non-automated tests.

I've never worked for a company that writes unit tests. These companies still had great code.

However, if you said they weren't using any type of source control, I might re-consider. However, You could also use this opportunity to move up in the company by implementing it.

I realize we are in a bubble, but trust me bubbles don't last forever. You need to think longer term. Ask anyone that was working in tech circa 2002.

The questions you should be asking are:

-How is the pay? What are the benefits like? What are the expectations for hours?

-Does my future boss seem like a person I can get along with? What about my co-workers?

-Does the company have a business model that makes sense (i.e. will their checks eventually start bouncing)?

-Am I going to be working with technologies that are in widespread enough use that I can get another job even after the bubble bursts (hint: you want technologies that are in use in "boring" corporate settings as well as start-ups)?

All of these are far, far more important than if they give you a fancy chair or MacBook Pros; whether they use SCRUM or XP; svn instead of git; etc.

There are good reasons for having unit tests, however, unit tests do not make a good product. It is the same automated tests, source control, etc... It could be said about most development paradigms. They are just tools in the toolbox. How you use those tools and the information they provide is what makes the difference. I've seen many cases of an urge to implement the latest & greatest "THING" in the internet, only to have it fall flat because it was complete overkill, wrong tool for the job, or simply poorly timed execution (you cant implement the "perfect world" overnight, it takes several iteration for the people and processess to catch up).

When you get there, if you think it would benefit them based off of their work style / processes / product, I would come up with a plan to start using unit tests and use this as an opportunity to climb the ladder.

An analogous question: Would you marry someone who doesn't floss? I mean, otherwise they're great, but there's all this hype around flossing and I thought everyone did it.

My last company was crazy about unit tests, automated testing and continuous integration. While I was there I did learn quite a few things (thanks to couple of very talented individuals). They even paid pretty well and the work environment was nice. However, I left after a year and would never go back. Unit tests don't make a great place to work. Our projects were always late, everything was over engineered and it was turned into a pretty frustrating work environment.

Unit tests, code reviews, pair programming, procedures, etc are all tools. Their use depends on the circumstances. In some cases unit tests are the absolute wrong thing to do. For instance what if you have been given two days to prepare a client demo on which a large contract rests. Unfortunately, a great many people have found that they can exist in the corporate world simply by complaining about things and never really doing anything. Either that or they don't know what their doing. These are the people who try to enforce rules like 'every commit has to be code reviewed' or 'every single line has to be unit tested.' Usually its at a small, new company where the guy put in charge is still beginner-intermediate level. In these situations there is usually cargo cult behavior going on and a desire to look like experienced devs by making stupid rules for everyone else.

no chance...unless it was to introduce TDD and BDD. It's a cultural thing. And I prefer to ship stuff that works as to the best of my abilities!