Evaluating a New Engineering Job
My friend and I recently discussed things to consider when choosing a new engineering job. My criteria assess the general organization and technical status. I think it’s extremely important to always move to a better gig, and sometimes it is worth it make a lateral move if there is more future potential.
I have written up a few areas that should be considered before accepting a new position. Each is a sliding scale. A decision should be made on the aggregate and not one one specific factor. Lastly I compiled a list of easily identifiable red flags.
Continuous Delivery Capability
I think continuous delivery is the best way to build software and internet products. There are many different ways to assess an organization’s position. The matrix lists easily identifiable signs. The organization should be at least in “Managed” in most of the areas. This is a great way to assess an organization’s confidence in their process and what it is like to ship software on a day-to-day basis. Generally the organization should have a positive trajectory and is moving to the right in all areas.
Organizational Impact Capacity
Its important to consider how much impact your work has. “Impact” is subjective. It may be a direct change in revenue, or doing something to improve the situation for your coworkers, it may even be driving the organization in a specific direction. Regardless, each person must define their own impact criteria and consider their role.
Growth Potential
This should be evaluated in two directions. First, what opportunities does the position provide to grow my career? Second, how far can I grow in an organization? The first one is more important because each person much come up with their own expectations on what they can achieve and where they want to go professionally. The second question helps to judge how much can be achieved in the given position.
Culture Fit
Each of us have our own personality and values. It is entirely possible that your values may conflict with the attitudes of others. Consider this scenario: you stop work after a given hour to have your personal time, however many others work around the clock and are upset when you do not. Culture fit is difficult to asses but it contributes so much to your overall happiness in an organization.
Key Performance Indicators (KPI’s)
It cannot be improved unless it is measured. Numbers encourage transparent decisions around facts. They also align everyone on what is important. You should evaluate how the organization measure itself and it’s members. KPI’s should be clear and relatable.
Immediate Red Flags
Usually it is easier to recognize what you do not want. We have all been burned by various things and we remember them well. There is also our personal preferences and various engineering/culture fit things. Here are some reasons I would reject potential employment. Personally I have no interest in working with a company that meets any of these criteria. I do have the capacity to help improve these areas but I do not want to spend my time and energy building up these areas.
- No source control. Yes, this still happens. If the company does not have source control, then they are working in an entirely different problem space.
- No continous integration. Simple, if there is no CI, then there is no tests. If there are no tests then everything is completely and utterly doomed.
- Manual and infrequent releases. Humans are horrible at following instructions. Manual deploys create more headaches than they solve. To me this indicates the organization does not have means to automate or do not see the benefit. I do not know which one is worse.
- No interest in the product. The company may be a product company. If I have no interest in using or do not see the value, then there is no point in contributing my time and effort.
- Remote work is outlawed. It is fine if the company does not embrace the “remote first” philosophy since there are many well thought out reasons not to. However if a company has fully come out against remote work on principal then count me out.
- Significant technical debt. This is difficult to gauge compared to the others. It relates to the organization’s overall technical health. I am not interested in working in an engineering department that has two hands tied behind their back.
- No engineering blog. I am extremely interested in learning about how the organization approaches, solves problems, and generally about the act of engineering at the organization. I cannot educate myself without this. I do not like going in blind.
- Uninteresting tech. I have reached a point where I know there is stuff I simply do not want to put up with on a day to day basis. The top of mind items are: closed source platforms, Java, C, Golang, C, and C++. One important rule for myself is: “if the languages requires me to write map myself, then I will ignore that language.” There are plenty of more appealing options. There are also frameworks (Rails) that I do not want to deal with as primary job requirements.
- No KPIs. Organizations need numbers to measure their success. These numbers must be built into the process. When the organization does not have any defined then it indicates there is a poor decision making process.
- Cheapness. There is a difference between frugal and cheap. Provide me appropriate hardware. It’s 2016, SSD’s are entirely affordable now. Do not penny pinch me over such details. Save money where it makes sense. Buying cut rate hardware and other tools is fantastic way to alienate me. Do not try to stiff me on pay either. It is a big market out there.
- No educational focus. I can educate myself on topics I am interested well enough. However there are things that are purely related the business’s technology stack or problem domain. Invest in me and there will be a return. Help me to help you.
- No metrics. “It’s not in production until it is monitored.” A system cannot be monitored without metrics. Monitoring can be a really tricky nut to crack, but if there is not any data on the system’s operational state then count me out.
