What is the Retention Rate?If the team you are considering joining has a poor retention rate then that is a red flag the size of Texas. This typically indicates that there are systemic constructs in place that are causing poor retention and it is likely to impact you - and your career - considerably and negatively. People do come and go, and if the best developer left for GoogleAmaFaceSoft or today’s hot startup, well OK, but if the average tenure for a developer is less than two years then something is terribly wrong.
All companies know at least anecdotally what their retention rate is, so ask about it. Ask what happened to the last person who joined. Ask for specifics, and ask both the recruiter and hiring manager. Don't accept evasion or inconsistency in these answers. Also talk to members of the team and find out how long they've been there. Since your job position is likely advertised as added headcount to a "rapidly growing team" really confirm this is the case.
Do you require a coding sample?No company should hire any developer without requiring a coding sample. The mechanics may vary. It may be a whiteboard only or pen-and-paper problem during the interview (ok). It may be a homework assignment (better). It may be that you submit information about open-source contributions or a link to your active GitHub account (best). But you should be evaluated in this way, mostly because you want to ensure that the others at the company you will ultimately work for have been evaluated this way.
The fact that a company doesn't require it indicates that they either don't know much about recruiting people (leading to lots of churn) or they are not interested in recruiting high-caliber developers. It’s best for your career to work with the best talent possible. Long story short: avoid any company that does not ask for a sample of your work.
Can I see where I'll be sitting?The company will likely take you on a tour of the office and point out things, but they probably won't necessarily show you where exactly you will be sitting. Ask your manager where this will be and ask to see it.
First, you need to know what the environment is like. Is it loud or quiet? Is it free of distractions? Private or not? Cramped or spacious? Is there abundant natural light? Ask all these questions and more to arrive at the answer to this one: Are you able and willing to do your best work there? (Beware of promises regarding "new" or "better" or "different" offices as the people who promise these things are generally not the decision makers regarding how the future space will be built.)
Second, you can use this as an opportunity to learn about the culture by seeing it as opposed to reading it on a website or asking about it. What rooms do you pass on the way to the office? Are there "toys" such as a scooter or someone's pet dog? Do people decorate their cubes for the holidays and put personal effects in them? Is there an empty liquor bottle on someone's desk? Sometimes what you don't see is just as important as what you do see. Take good mental notes and allow this to impact your decision – after all you’ll be there for 8+ hours a day.
What tools are available to me as a developer?Your company should be willing to provide you with the best tools that money can buy. Even the most expensive tool pales in comparison to the cost of a developer. If the company is not willing to invest in great tools than this can be generally extrapolated to mean that the company is not willing to invest in the development team as a whole.
This can be a bit difficult to probe for. When talking to a development team member, ask about the IDE setup. For Java, if the company shuns IntelliJ in favor of Eclipse due to cost, you have your indicator. For .NET, if the team doesn't use ReSharper due to cost, same thing. Ask the manager what the process is for purchasing a useful piece of shareware or a book (it should be minimal - "just buy it and turn in the receipt" is best). And, find out what the computing rig you will be using is like. It should be generally described as "new, state of the art, with two monitors".
What will you do to help me grow?It is essential to understand both the tangible and intangible things that a company does to invest in you and the development team as a whole.
Find out what activities the employer does to encourage you to grow in the field. So many potential employers extol the virtues of open source software contributions, attending conferences and being recognized in the field, but many companies don’t do anything to foster these things within their own teams. I don’t think “20% time” (ala Google) is reasonable to expect, but the company should put some skin in the game when it comes down to it. How to tell? Ask what the company policy is regarding time off if you were invited to speak at a conference. Would you have to burn your own vacation time for it? Would the company pay for your travel expenses? Also find out if your company sponsors any meetups or user groups, or otherwise encourages attendance to these types of events.
It is also important to gauge a company’s interest in keeping current. It is not uncommon to deal with legacy systems and languages, but the company should be generally interested in using modern tools and doing new things. Find out how the reaction would be if you were to propose a new programming language or major system change (e.g. new source control, swap out the ORM mapper, etc.). The best companies debate these things – oftentimes fiercely – instead of responding with a knee-jerk “no” or “we don’t have time”. Another evidence-based approach is to see what the developers of the company contribute in terms of blog postings, open source contributions, and so forth.
What were listed as some of the things that are "done well" from the last retrospective?So you're joining an Agile team. All (four of) my readers believe in Agile and don't want to work on a Waterfall team. No problem, you say, because the position description mentions it. Don't take anyone's word for it - many teams are actually doing Waterfall but say they are Agile, or are "transitioning" to Agile, or are doing some chaotic development process that they simply call Agile. My favorite question to root this out: When was the last retrospective, and what was indicated as done well?
If the team does not do retrospectives then you are not joining an Agile team. This is a good launching off point to ask other questions about the engineering processes in place and learn about how projects are managed. Be sure you are comfortable working in the framework that is in place and be sure that the team is engaged in confronting the issues that make development inefficient.