What to Consider in a Software Engineering Job
*Preferably before you take it
Being a young Software Engineer, I spend a lot of time worrying whether I’m on the right career path, whether my current job is a good fit for me, whether I should look for other opportunities, which ones to apply for, which one to actually accept, and other overwhelming questions like this.
Over the time, I’ve been accumulating a list of factors that I should consider when evaluating a job. Some I discovered from experience, some from colleagues, and some from blogs or podcasts, and, more importantly, some I learned the hard way. Now that I have a decent list, it might be a good idea to share it hoping that others will find helpful, and add their own suggestions.
Of course not all these factors should be equally valued, but I believe that the priorities can vary greatly depending on what you want out of a job at that point of your career. Anyway, I tried to arrange the list in some rough order from my perspective right now. I’d be interested to see how you might shuffle this order and what you might add or exclude.
I will favor breadth over depth in this list i.e. I will try to mention more points, and leave it up to you how to evaluate them.
1. Technical Challenge
This is something that will make a huge difference in the experience you gain. Will you be building simple websites for clients? or working on a platform with complex architecture?
Some companies are content with making the same product over and over again for some steady revenue, while others are taking risks and pushing the boundaries of technologies — or creating their own. Choose a company that shares your personality.
This is the rather personal variant of #1. Do you really care about the product(s) you will work on? Do you think it makes the world a better place? Do you want your name to be on it? Is it something you want to devote most of your waking hours to?
To me, this means going to bed —on some days at least — feeling that someone’s life got a tiny bit better because of your work, and waking up excited to do it again.
Some companies also offer developers some off-project time to work on any ideas they have, which is pretty awesome if you like to have some autonomy.
Chances are you are going to switch your core technology a few times in your career. Ask a blackberry or flash developer for instructions.
You should always worry more about being a good software engineer, than being a good java developer, for instance. Focus on abstract concepts and recurring patterns, not just on solving particular problems.
This does not mean that you should not love the technology/language you use. Being excited about it is something that will motivate you to go the extra mile. However, don’t get too comfortable with it. Don’t let it dictate your choices. You will have a hard time going through your career with a narrow skill set, and you can’t possibly learn every new framework that comes up.
If you are considering a shift, do some research about the new skills you will learn and make sure they will be relevant for your career in the long run. I certainly wouldn’t advise someone to switch to VB right now.
What will you be doing exactly? Will you be maintaining old code? Writing small modules? Designing new solutions from scratch?
Will you be working with one framework/language all the time? Switching between a few environments daily?
It’s very important to know your exact scope and how it fits in your career plan before accepting a job, or you risk having the wrong expectations. Other than that, think about the career path this jobs offers. Will you be able to move to a different role? When? What is it?
I personally favor a leader who is open to new ideas and ways of thinking, willing to experiment with new technologies even if it wastes some time, and who I can communicate with spontaneously and frequently. And above all, someone I can learn from. Be sure to meet your leader and get to know him before you accept an offer.
“If you are the smartest person in the room, then you are in the wrong room.”
Some teams will push you to grow, others will slow you down. Try to work with people who are better than you and are fun to work with.
Team size is something to consider as well. Medium and large sized teams usually provide a more diverse and creative work environment, and so do teams with people from different backgrounds.
Of course it matters. It can be the difference between focusing all your energy on the job, or dividing it on freelance projects to earn some extra cash.
This is probably a factor whose significance can vary substantially for different people. But a simple rule is that it should be enough to cover your expenses and financial commitments, match the average for your experience in your city, and feel fair enough for you. Don’t be shy to discuss all the details before you accept an offer (base salary, bonus, raise, profit shares, overtime, transportation, …)
Another thing I’d take into consideration is overtime compensation. I found that companies who do not compensate employees for overtime are more likely to overload them. Because it becomes an easy solution for project managers when they’re behind the plan. While if it is compensated, they probably have to get financial approvals and justify the situation to their managers, at least they will think twice about it.
It’s important to know in detail what software development process they follow (agile, waterfall,..), how strict they are about it, and what tools they use to track it.
Ask about code review and code standards. Try avoid companies who skip this step, or you will end up hating your own code, or, even worse, be OK with your crappy code.
Check if the company has technical training or career development programs. These can be very useful if you stay at the company for a long time.
Try to learn about their evaluation process and how your performance will be measured.
It’s OK to work extra hours or days on something you care about, but just make sure you know that upfront, and that it fits with your other priorities in life.
Flexible hours and working from home are very nice to have.
Reputation, size, hierarchy, stability?
Is it a software company or an IT department of a company? How dedicated is it to software products?
Does it have a technical blog? Does it participate in technical conferences and events? Does it have any open sources projects?
11. Other Benefits/Perks
Medical insurance, annual holidays, office space, machines, location, free snacks?
Now before you go I should probably leave you with this disclaimer
- I tried to list as many factors as I could, but there’s definitely room for improvement on this list. Feedback appreciated. I’ll try to update it every now and then.
- It’s unlikely that you’ll know all these factors before you accept a job. At least make a list of your top priorities. Squeeze the relevant questions in the interview, ask people you know at the company, do some research, or send them an email if you pass the interview.
- No job is perfect. Figure out what points are critical to you and what you can sacrifice.
- Don’t ignore your intuition. There will be reasons you can’t quite name. Evaluate the risks/rewards, and make your decision.