Some of the better questions to ask are:
- How often do you add new tools to the mix?
- Do you tend to roll your own solutions more often or rely on third party tools? What’s the rationale in a specific case?
- What kind of test coverage do you have?
- How long are your release cycles?
Questions like this give you a very good idea of the behaviour of the company. If there are new tools added all the time then someone is just trying the flavor of the month language/library/framework/database. If there’s more home-made solutions than 3rd party tools, you will have to find out how high or low the quality of those solutions is and whether they’re documented well (or at all).
Test coverage is the most revealing question as a coverage of under 50% is dangerous when you’re trying to add new features. Low test coverage could mean possible regressions. Higher test coverage can indicate a good code review or pair programming process.
A release cycle that takes two weeks is only normal depending on the industry. If you’re interviewing at an embedded hardware company or at a consultancy with a government contract, a longer release cycle is normal. If you’re at a Software-as-a-Service company, the release cycle should be as short as possible.
[So what does this article have to do with open source? nothing. However, we all want to work in an industry that values quality and professionalism and finding the right job for yourself is a key component of that.]