In a recent interview I asked the interviewers "how do you go about evaluating new technologies and libraries (such as SignalR) and bringing them in to use?". They said they don't, that instead they write everything themselves so they don't have to rely on anyone else.

The firm doesn't work for the government or defence contractors or on any safety-critical projects or anything like that. They were just your average, medium-size software development firm.

My question is: how common is it for teams to write everything themselves? Should I be concerned by teams that do?

Edit -- Most every response has said this is something to be concerned by. Would a second interview be an appropriate time to ask them to clarify/repeat their position on writing everything in house?

An attitude of never using third-party libraries is preposterous.  Writing everything yourself is a horrible use of your company's time, unless there is a strict business requirement that every line in the codebase was written by an employee of the company -- but that is an unusual scenario, especially for a private-sector firm like you've described.

A more rational and thorough answer may have been that they would only use third-party libraries that:


Meet the needs of the code they would otherwise write themselves
Were available under a license compatible with the company's business model
Included tests
Passed a code review 


If those criteria were met (and in my experience the code review is very flexible especially in the presence of good tests), you're no longer "relying on anyone else" -- you're relying on existing, available, and preferably robust code.  

If the code is open source, then in the worst case, the third-party library becomes unmaintained.  But who cares?  The tests prove that the library is suited for your needs!

Moreover, an aversion to established third-party libraries seriously hinders programer productivity.  Let's say the company was writing web applications and refused to use (e.g.) jQuery, so instead wrote their own alternative cross-browser library for simplifying DOM manipulation.  With near-certainty we can assume that their implementation:


Will have an API foreign to developers already familiar to jQuery
Will not be as well-documented as jQuery
Will not have relevant Google results when encountering problems using the library
Will not be as field-tested as jQuery


All of those points are major barriers to programmer productivity.  How can a business afford to give up productivity like that?



You've updated your question to ask whether this is appropriate to bring up in a second interview.  It absolutely is.

Maybe you misinterpreted your interviewer's answer in the first interview, or maybe the interviewer just incorrectly explained the company's position and a new interviewer can clarify it.

If you explain that you're concerned about their stance on external libraries, there are at least two possible outcomes:


They're open to change, and your concern about their process makes you look better than some other candidates.
They are not open to change, and they think of you as "the kind of developer we wouldn't want to hire."  Doesn't matter, that's not the kind of place you want to work anyways.

