Will You Happier In a New Job?

In my last post I discussed some things that influence happiness in your job. But if you are not currently happy, would you necessarily be any happier in a new position? Unfortunately the problems I discussed in that post will generally not reveal themselves for some time after you start a new job. Hence you will be engaging in a guessing game when you interview with a new company.

Still, there are some things you can investigate about the company, either during the interview process or through your own research, that may shed some light on whether it’s a place where you'd want to work. This approach is far from foolproof, but it may help you avoid making some bad decisions.

The first question is whether the team engages in CRUD development, and whether it’s a cost center or a profit center. I’ve talked about these topics before, but they're always worth keeping in mind when evaluating an employer.

Next, is the team engaged in new development, or are they maintaining an existing system?

Do the engineers that you interview with know their stuff? Do they understand the raw technology as well as architecture and design issues? Can they intelligently discuss the system they work on? Are they enthusiastic about the work?

Next, do they use source control, and have a formal team handling builds and configuration management? Do they properly use labels, branching, and merging? Some organizations may be too small to have a dedicated build team, but they should still use sound source control practices, and they should have a configuration management specialist.

The same questions apply for production, especially in a web environment. Does the company have dedicated dev, testing, and production server environments? Do they have a controlled production process with regularly scheduled releases? Avoid companies that try to do production releases on a daily basis, unless you want your hair to turn prematurely gray.

Does the company have architects? And by architects, I mean highly experienced engineers with 10+ years of experience whose job it is to advise teams rather than do coding day in and day out. If they do, it tells you two things: 1) that they take their technology seriously, and 2) that they value technical people enough to provide a purely technical career advancement path.

Does the company have product managers? It’s not necessarily the presence of product managers that results in better code, but having someone directly responsible and accountable for feature sets and requirements can help reduce uncertainty in planning.

Finally, does the company use Waterfall methodology? If they say don’t have an explicit methodology they’re probably using waterfall by default. Some organizations do actually manage to use Waterfall effectively, but chances are most Waterfall organizations will require a deathmarch as the deadline approaches.