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?

  • 58
    Huge red flag. Walk away calmly and make no sudden moves.
    – tdammers
    Commented Apr 20, 2013 at 19:12
  • 16
    I don't think this is as ridiculous as people say... Recently I've wasted an incredible amount of time fixing abandoned libraries for new framework versions, new versions of libraries with severe breaking changes that weren't documented and even huge gaps in significant frameworks like jQuery that make them not fit for purpose. People don't put enough effort into deciding whether third part components will add huge maintenance overhead and often end up with a pike of unmaintainable spaghetti dependency hell. Commented Apr 21, 2013 at 8:08
  • 4
    NuGet is awesome, but makes it so easy to do this. I installed some trivial helper library from NuGet recently, and it pulled in Castle and all sorts of other bloated crap. Sure; an outright ban is strange, but it's no more stupid than allowing every dev and his dog to randomly pull stuff in without real thought. Commented Apr 21, 2013 at 8:10
  • 13
    Everything? Does that include their own browsers, operating systems and compilers? Otherwise they are just deluding themselves. Commented Apr 21, 2013 at 16:00
  • 4
    Of course it's as ridiculous as people say. The fact that a) it's possible to choose the wrong library for the job and b) there are situations where no third party library available will meet your needs better than an in-house one: does not mean that blanket policy of never using third party libraries is correct.
    – user16764
    Commented Apr 21, 2013 at 17:42

11 Answers 11


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.
  • 1
    +1 but I think you meant private sector, not public sector.
    – MarkJ
    Commented Apr 21, 2013 at 6:49
  • 6
    "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!" You also have the source code, which puts you in the position of having what you are using now and being able to update it to meet any future needs. (Yes, getting used to an "alien" code base takes time, but so does rolling your own.)
    – user
    Commented Apr 25, 2013 at 8:36

That seems incredibly uncompetitive. I've worked in shops that decided to skip the standard open-source libraries like Hibernate and roll their own due to some "critical" missing feature. In the end the software was incredibly expensive to build and maintain. Of course the expense of the in-house library was grossly underestimated. And while the in-house library was written, the standard libraries advanced rapidly, adding new features that weren't available in the in-house library. In the end, work that would take an hour using a standard library instead took two days. And it was bad for the developer's careers, as the world passed them by. I would avoid a shop like that. I like to deliver, and don't have the patience to rewrite when I could reuse.

  • 2
    Since the developers no longer had relevant skills for other jobs, company money lost on extended dev time was saved by not having to replace departing team members! #stratgey Commented Apr 22, 2013 at 19:40
  • @Michael: The only people they could retain were the people who were present for the original decision to create in-house frameworks. New hires tended to leave after about a year. Commented Apr 22, 2013 at 22:56
  • </itwasaweakjoke> Commented Apr 23, 2013 at 1:47
  • +1 If the missing feature is really, truly, crucial: modify the open-source library and contribute the feature into the main source. Delivers great business value, makes everyone feel good and it's excellent for everyone's CVs because they now have now made an open-source contribution.
    – MarkJ
    Commented May 20, 2013 at 10:56
  • @MarkJ: but if the change is rejected, someone will have a bruised ego. Commented May 20, 2013 at 15:20

The shop has a disease called Not Invented Here. It is a good reason to terminate the interview on the spot and leave immediately. This can only be cured by a top-down house cleaning that is very unlikely to happen.

To answer your question, it is sadly much more common than you might think and it's definitely a reason to be concerned.


Yes, definitely be concerned! That reeks of arrogance and (sorry to be harsh) stupidity. Any programmer with half a brain will use a library like signalR instead of writing it yourself. There is absolutely no point in wasting your time solving a problem that has already be solved. I would possibly try to find out more information first - they might have misunderstood you (might be difficult though if the interviews are over!)


I have a couple of friends who have both (briefly) worked at software houses with not invented here syndrome. So the mentality is out there.

An observation they both made was around the culture the approach fostered in the development teams. They both ended up working with people who were quite insular in terms of their outlook on software development, and people who were not really driven to learn new things and push for quality. Regardless of what stage you're at in your career, you would always like to be working somewhere where you stand a chance of learning new things from your peers. This sort of environment however seems to generally not be found in places that wish to roll everything themselves.

  • +1 one of the main reasons I moved on from my previous employer! Commented Apr 23, 2013 at 19:16

It's not common where I live, and I know a lot of companies though colleagues. I'd go as far to say it's an immediate "no thanks" from me.

I won't regurgitate the good points already made, but I will add one thing.

They have just made hiring a lot more difficult.

  • All new hires have an even steeper learning curve than just the main part of the software/domain
  • The best candidates will be put off as they will not want their skills to become unused.
  • People are not likely to stay around long once they realise how bad it is not getting to use their favourite tools, and staff turnover is expensive

Now there will of course be people who like the challenge, but I think they'd be in the minority.

And equally, there will be some companies who operate on "Internet scale", Amazon, Facebook, etc., where they have insane custom needs, but again these are in the minority.


I don't think a software company can survive today without relying on third party and/or open source software, and in order to remain competive they of course need to actively keep track of new technologies. There are often good reasons, however, to take at least a rather defensive view on it.

As an example, if you sell software and claim to provide 24/7 support and also are legally responsible for your software to operate correctly, then you need to have a very precise idea of what is going to happen if there is a problem with your software in, say, a factory where 1 hour of production downtime may cost several millions of dollars, and then a serious bug happens to be in that open source library you were using. Believe me, you will perform very thorough assessments of the software in question.

From what you've written this scenario does not seem to be at the heart of the matter, though.


If you are a technology based company of a certain size, than it would seem that you will be developing more and more of your own tech, for example: google develops alot if not most if not all of their software while open sourcing most of it in the pursuit to make it an industry standard.

For smaller companies, it would seem like an utter waste of time when they're trying to ship a specific product with it's own business logic, and in my experience I haven't seen that small-medium sized companies do so.

It becomes more intricate when you're talking about heavily-specialized code base, for example: encryption algorithms - some people have a basic understanding on how they work, but the intricate parts of actually implementing a solution would seem like shooting yourself in the foot unless you hire a cryptographer which specializes in such things.

Some companies do allow freedom to create your own open source projects, which seems more appropriate.

I would personally not go to a place with such culture.


What you've got is a really good opportunity to go into the second interview and ask them some tough questions. I don't know what the company does so it's difficult to say why this seems a strange choice. You could use the comment by @Daniel Pryden with regards to Google's usage of third party libraries.

Any piece of software you use, whether it is in-house or from a third party has advantages and disadvantages. Not to use a tool because it's not in-house, even if it is the best tool for the job shows a certain closed mindset and that's never going to encourage innovation and creativity.

Perhaps though, just perhaps, you're the person to introduce that change. Good luck with everything.


Of course you should walk away. I haven't seen it mentioned here, but the biggest reason to pass over the job is because you won't gain much in transferable skills.

Imagine at your next interview when they ask what technologies you worked with and you can only mention bare bones C++.. That sounds like graduate level

  • "I haven't seen it mentioned here" - did you look at other answers, for example at this one?
    – gnat
    Commented May 20, 2013 at 6:18
  • 3
    Wont gain much in skills? Thats rediculous. Thats only true if you view programming as playing with Lego blocks, stacking components together. If you have to 're-invent' a library, you're going to learn an awful lot about a particular topic. Commented May 20, 2013 at 16:34
  • @GrandmasterB You are correct, allow me to clarify - A lot of places ask what tools you worked with. Your chances of getting overlooked are much higher if other candidates can hit the ground running while you would have to learn from scratch. Commented May 20, 2013 at 17:21

Big companies write everything themselves.

There are several advantages in writing it yourself:

  1. You're guaranteed to own the software yourself
  2. You can correctly calculate work amounts that went into creating it
  3. Repeating your steps becomes possible even if next time the libs are not available
  4. It cuts down your requirement bloat
  5. You're not repeating what others have done already
  6. You're guaranteed to have enough people to maintain it
  7. You can modify every part of the software
  8. Software size is limited by amount of resources you have

Here's how each of the points break if you use someone elses library:

  1. Someone else owns the lib
  2. You don't know how much effort went into creating the lib
  3. Your next version of product is impossible to create on new platform since same libs are no longer available
  4. Ability to implement requirement is dependent on whether the lib implemented it years ago
  5. Someone else also uses the same lib, getting same limitations and features
  6. Since you didn't create the libs, you don't have enough people to maintain all the software in your product
  7. Libs are binaries, nonmodifiable. Even if source is available, you don't have enough people to modify that large amount of code.
  8. Maintaining the code you created + the libs is bigger effort than you originally estimated
  • 7
    Wouldn't the logical extension of these arguments be to also write your own compiler (probably for your own language), run this software on your own OS, and probably build your own HW too?
    – timday
    Commented Apr 20, 2013 at 17:59
  • 4
    1: Yes and I can pay a fee to use it (without spending money to build it way the difference in cost). 2: If I am not building it I don't care. 3: In business platforms are slow to change. Staying cutting edge is rarely a requirement. But good software moved easily. 4: Not true. You just transfer the bloat from external to internal. 5: Does not make sense. 6: Not true. 7: True but means you need to divert your precious programers (the most expensive part of a project) from real work into bug fixing on something that could be maintained elsewhere. 8: That's a bad thing. Commented Apr 20, 2013 at 18:08
  • 5
    Many big companies make extensive use of open source code in various forms (including libs), often improving on/contributing to the relevant projects. The points are mostly irrelevant or incorrect.
    – Matt
    Commented Apr 20, 2013 at 18:21
  • 7
    @tp1: I work for Google and I can assure you that Google very much does use third-party libraries when they meet our needs. Many times Google has needs that are unique or at a different scale from many other software companies, so for one reason or another Google will often develop things in house. But Google also uses a large number of open-source libraries, and/or open-sources lots of internal libraries, so not everything is in-house. Most of your points no longer apply for open-source software, since by having the source you ensure that you can always debug it and fix it if necessary. Commented Apr 20, 2013 at 23:14
  • 5
    "No, the value comes from accurately implementing the requirements. If it was built before requirements were known, it cannot accurately implement those exact requirements." Clue: If you think this argument has any merit at all, then you've failed to understand separation of concerns.
    – user16764
    Commented Apr 22, 2013 at 18:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.