4 More Questions to Ask Before Joining a Software Company

Today I read the excellent blog post “7 Bad Signs not to Work for a Software Company or Startup” by Stephan Schmidt.  I agree with him completely.  An interview is a two-way street.  If you are worth your salt you are interviewing them as much as they are interviewing you.  You definitely should be ready to ask some good questions.  As it mentions in Stephan’s post you definitely need to ask the basics about the company as outlined in “Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup.”  Those are all about basic company health and business stability – definitely something you want to factor into your thinking no matter what your level of risk tolerance is.    But those questions will get you data about the company.  Here’s some I recommend to get data about the team and about the software development process…. in other words, about the stuff that will affect your everyday life if you join them:

1.  Tell me about your development infrastructure – build tools, source code control, bug tracking software, that kind of thing.  What do you use?

The company should be able to immediately explain all the tools they use.  If the person interviewing you cannot, you are not close enough to the team!  Ask politely to meet with someone who can explain these things in detail.  I’d ask why that person is not on the interview team too!  The answer should of course be dependent on the technology stack, but there is a lot you can learn about a company based in the answers.  For example, if they use ClearCase for source code control they may be inclined to more rigorous process and be big enough to carry the overhead of that system – which may mean they are a very big machine and you might be a very small cog.  If they use Git/GitHub, they are likely small and nimble and very much in the modern era.  Perforce, someplace in between.   Ask *why* they picked that system.  A good Manager can explain it clearly.  I personally think that most teams should have an automated build system triggered off code checkins.  It should at least build daily.  I like team emails of the results – especially broken builds.  Nothing encourages good habits like public humiliation for breaking the build.  Ask the Manager if they do anything like that.  Ask about how they track bugs.  Do they have a bug life cycle defined?  If they don’t use a software system for tracking bugs that’s just as bad as not having source code control, in my opinion.  You can learn a lot about the organization by what they use, but also by how the interviewer presents that information to you.  A shop you want to work in will have a Manager who can explain it all clearly, including why they made those choices.

2.  What’s the team like?  How long have they been here?  What’s their strength?  Weaknesses?  How would I fit into the team?

I personally always involve my team in the hiring process.  At PRN we usually do four hour interviews where you see at least four people.  I love that level of commitment to the process.  I have several of my senior Engineers conduct an hour or so interview each, and then try to make sure that at least one person who would work directly with the candidate as a peer gets a time slot too.  My time with the candidate is usually spent answering questions and describing the company – my phone screen is often most of the technical stuff I ask.  I can do this because my team is deeply technical and they don’t tolerate less than that.  They’ll dig deep into what someone knows or does not know, and they won’t want anyone who cannot contribute.  I trust them, so I let them run with that part – after all, they are the ones who will have to carry someone who cannot contribute technically.  I concentrate on understanding if the candidate can communicate, is passionate about technology, and if they will be a good fit overall from a people perspective.  This process is not for everyone, but it solves the issue of checking to see if the team will mesh with the candidate and lets the candidate decide if he or she likes the team.  You should at least get a detailed explanation of the team structure, who is responsible for what, and what their strengths are.  I’d personally push for meeting them in person.  Your work mates will get more of your time than your family and friends do… you owe it to yourself to learn early if you are a fit with them.  But make sure you ask the hiring Manager this question regardless.  In my current role I can answer that I have the best team I’ve ever worked with, and that everybody is a strong Engineer who can communicate well, who can ask for and give help and advice freely, who can be trusted to carry their share when the load gets heavy.  If the hiring Manager instead complains about the team or has no opinion, that’s a red flag.  You need to understand more about what’s going on.  It might be a bad team, but it might be a bad Manager.  Either way, you probably need to know more.

3.  What’s your development cycle like?  Do you usually hit your dates?  Why or why not?

This is a great question to ask each of the team members and compare their answers.  If the hiring Manager gives you one answer and the team gives you a radically different answer, you might want to reflect on that.  Every business is different and every team has it’s own cycle.  Is it month long scrums?  Quarterly releases?  Production code pushes every week?  A real business will have a defined cycle.  If the cycle depends on customer whims that might or might not be a problem, depending on the business.  A team that is constantly missing dates has a problem someplace.  It might be that Management is overly optimistic and is failing to give the Engineers enough time to do the work.  It might be that the customer is setting crazy expectations and the business cannot say no.  It might be that the team is very bad at estimating.  Regardless, this question will provoke some kind of answer that will tell you more about the work environment and the stress level that you will be exposed to.

4.  How do you QA your software?  Do builds to QA get rejected very often?  How many builds are needed on average to get a ‘release’?

This is the killer question as far as I am concerned.  The hiring Manager should be able to discuss the QA process in detail.  Ideally, it’s a formal process, but smaller startups may not have it all that formal yet.  I like to hear a hiring Manager who starts off any discussion of quality with some points about how it’s cheaper to fix issues early, how good design beats bandaids later, how unit tests up front save weeks later, how a release checklist prevents stupid mistakes from thrashing your QA team with builds that are broken.  I think the hiring Manager should be able to discuss whether there is an automated regression testing system or not, how test cases are planned, if they are reviewed with the development team, how they are tracked against being test complete.  If they can, that’s a good thing.  If they are clueless, you might want to worry.  If they blow smoke, you may want do wonder how bad you want to work there.  The way they answer it is as valuable as the answer itself.  It will tell you a lot about how the organization thinks about software development and software quality, and that has a direct impact on your life there.

I think that these four questions can tell you a lot about the actual nitty-gritty of the shop.  The answers – and how they are answered – will give you a lot of information about what your life might be like if you join that company.  A smart company will want you know this stuff.  Where I’m at it takes several months to find a good candidate to make an offer to (well, it took that in better times when we were hiring… it might take less now if we were hiring given the economy).  It takes a few months for a new hire to really get up to speed (our system is pretty complicated, and there’s a lot of environment stuff to learn too).  Losing a new hire after 4-6 months because they feel like they didn’t know what they were getting into is EXPENSIVE!  That means a net 8-10 gap of productivity since we then have to go hire someone else!  Much better business to just be up front about it… and better basic human behavior too.

But these are just my opinions.  What do you think?  Did I miss anything important?