You're in an interview, getting asked dozens of questions. At the end of the interview, the interviewer asks if you have any questions about the company. Heck yeah! This is your time to learn about the company. Getting hired is a commitment from you AND the company.

Interview

While I haven't had a lot of jobs, I have certainly enjoyed some more than others. Sure, at the end of the day it's just a job, but you'll be averaging about 40 hours out of each week there, so it better not be that bad. That's a significant part of your life. If my math isn't too bad, it works out to be about 10 years of your life working for someone else.

Obviously, it's incredibly important that you enjoy your 10 years as much as possible. So what do you ask a prospective employer about their company? I've come up with a list, semi-inspired by The Joel Test. These questions are more open-ended, so that it's more difficult to cheat. I recommend asking them, and writing down the answers for reference.

What type of source control do you use?

This question will confirm that they do actually use source control, and it will tell you if it's ridiculously out of date. If they say that they use Source Safe, be worried. If they're using something modern like Subversion or Team Foundation Server, that says something about them.

Do you have an automated build system?

Ideally, they would be running a continuous integration, but any kind of push-button automated build system is great. If the parts of their software are unorganized, and the developers frantically try to piece it together on the day of a release, run away!

How do you track bugs?

This question first tells us IF they're tracking bugs. It can also give some insight into how bureaucratic they are. If it's a bug tracker that lets every pencil-pushing, bean counter add a field, bugs will never get entered. I don't care how big your company is, it IS possible for you to run something simple with only a few fields. The likelihood of their bug database being up to date is inversely proportional to the number of fields on the bug screen.

Do programmers have quiet working conditions?

I can't really stress this one enough. If you're working in a close-knit group of developers that are all working on the same thing, then the occasional distraction isn't so bad. The conversation will often be related enough that you should know about it anyway. On the other hand, I've worked in a department where everyone had drastically different jobs. The noise was unbearable, and productivity was horrendous.

What development tools do you use?

This should ultimately cover hardware as well as software, so it might require a follow-up question depending on how it's interpreted. You want to make sure that the company understands that every minute you have to wait for your computer to compile, is a waste of your time, and a waste of the company's money. You also want to make sure that they're willing to buy the tools you need to be efficient. Developers are not cheap, both salary-wise, and in overhead costs. If they don't understand that, then look somewhere else.

What is your QA process?

This question tells you if they've thought about QA, and if they have, it tells you if they realize that testers are needed to produce a truly great product. This should also overlap with the type of testing that the developers are involved with. Unit testing has definitely gone mainstream, so look out for companies that are behind the curve, or think testing isn't worth the time and effort.

Do you do usability testing?

This is probably parallel with the QA process. They should have a clear way of determining the usability of the product, and have a way of finding out weak spots.

How long are your development cycles?

This isn't necessary a deal-breaker, it might just give you an idea of how it matches with your own preferences. I've worked for a company that had development cycles measured in years using the Waterfall method. I've also worked for a company where the requirements changed weekly, and we had to continually adapt. Both had their advantages and challenges.

Is the work environment fun and friendly?

This might not be a question that you can ask directly, but it's one that you should try to answer. Is there a strict dress code and set hours? The last time I checked, your computer doesn't care when you're using it. Your prospective employer hopefully understands that while it's useful having everyone in one place at the same time, flexibility is a must for maximum productivity.

How do you plan and schedule new projects?

This should give you insight into how much thought they actually put into what they're doing tomorrow. You might be able to get an idea of whether they're short-term or long-term thinkers. Having a map is a good sign, but being flexible is just as important. Only a fool would think they can plan everything perfectly, but they should also be solving problems before writing code.

What is the ratio of code maintenance to new code being written?

This is another personal preference question. If you don't like maintaining someone else's code, the answer to this one might be very important. You will also find out if you have to live with your own old code. Some people like the stability of a mature code base, and some like a fresh start every once and a while.

How does the company plan to grow and stay competitive?

This is a very broad question, but it does show that you're looking for a career and not just a job. It would be nice to know that there are smart people running the company, and they have a plan to be around tomorrow.

Conclusion

Do you have any software development related questions that you always ask a prospective employer? Please leave a comment and share them.