With the market for developers so fierce, we can afford to be a little more careful about where we work.
Over the years, I’ve interviewed at several companies. Whenever we got to the part of the interview where they asked what questions I had for them, I had plenty of stuff to ask about their tech stack, but not as much to ask about their working environment. Here are 10 questions I wish I’d asked at every interview:
- How many hours a day do you require from your developers?
You’d be surprised how many places expect more than 40 hours. If they want you to work 45 or 50 hours a week, it’s best to know that up front, so you can negotiate an appropriate salary.
- Do you allow working from home? How many of your developers work from home at least once a week?
A lot of companies will say they allow working from home. If they’re actually committed to it, though, they’ll be at least one or two developers taking advantage. If no one works from home, it’s because it’s discouraged by management, or they don’t really have the infrastructure (VPN, etc) in place.
- What is the timetable for getting vested in shares?
A critical question for startups. They’ll usually ask you to take a lower salary in exchange for shares. But if those shares take 5 years to become vested, you’re looking at a long wait for a risky payoff. Do you really want to sacrifice money in the bank for that long? Best to make an informed choice.
- Do you have “office hours” you like your developers to keep? What are those?
Most places are flexible, but have some sort of core hours they want you to keep. These may not fit your natural schedule (I’m personally a morning person, but I know a lot of developers that prefer to code at night).
- What’s your leave policy? Are Vacation and Sick Days lumped together? How many do you give a year?
Several startups are offering unlimited leave these days. It makes sense; if you’re a salaried employee, paid per year to get a job done, does it matter how many sick days you took?
If they won’t go unlimited, consider bargaining for increased vacation instead of a higher salary. You’ll thank yourself later.
- What’s your process for changing internal tools - e.g., if you were to change version control systems, how would you go about that?
Over the life of any piece of software, your tools are going to change. Is this dev team ready to handle that?
- Do you allow developers any time to work on open source projects, or just projects of their own for the company?
You’re going to want to spend time on your own stuff, whether to try out a new language or keep your skills up to snuff. You’ll probably want at least some of that to be open source work, so you can show future employers your coding prowess without violating NDAs. If your new job won’t let you invest in yourself, will they pay for training or conferences to compensate?
- What’s your employee review process? How often do you do employee reviews?
Ideal would be reviews after 30, 60, and 90 days for new employees, with everyone else getting evaluated every 6 months. You need the feedback an employee review can give, and they should want to hear from you.
- Do you do code reviews? How often? What’s the process?
Feedback, feedback, feedback. One of the fastest ways to grow as a developer is to have other people read and comment on your code. Frequent code reviews mean the team is committed to getting better.
- Do you do project reviews? What’s the process? Alternate: How is the performance of the dev team as a whole measured?
Another feedback question. Again, you’re trying to see if the team is serious about getting better.
These questions won’t cover everything, but they’re areas we developers often forget to check when looking for a new job.
