The world of professional software engineering is full of titles and grades. Employers use job titles as a means to help them build new teams with the right mix of talent, attract the right caliber of candidates when hiring, create attractive career paths and assist with compensation planning. However, many companies assign titles differently, making their systems difficult to understand, especially for younger engineers.
Sometimes employers will be very precise and define an engineering career track that might look like this:
Sphere of Influence
|Associate Engineer / Junior Engineer / Intern||0 years||Bug fixes, minor feature||Self|
|Software Engineer||1-4 years||Features||Team|
|Senior Engineer||4-8 years||Modules||Development Group|
|Principal Engineer||8-12 years||Product, Architecture||Company|
|Fellow||12+ years||Products, Technical Strategy||Industry|
This model is most often used by companies with large and well-established engineering teams.
Other employers use grades that sound more like movie sequels than job titles:
- Software Engineer I
- Software Engineer II
- Software Engineer III
- Software Engineer IV
- Software Engineer V
It probably won’t come as a surprise that the above bureaucratic-sounding titles are very similar to the definitions used by the US Department of Labor.
While it’s less common, some companies even drop the concept of job title progression completely and have everyone be just a plain old “Software Engineer,” regardless of their experience or talent. This can work wonders by preventing the formation of ivory towers and by empowering younger engineers to participate at the same level as their older peers. However it can be more difficult to implement because it goes against most people’s traditional (or even cultural) expectations, and it can cause unease for those engineers who strongly equate title changes with career advancement.
Given that there’s no standard structure for engineer progression, a Principal Engineer moving to a new company could be offered the less impressive-sounding title of Software Engineer, even though they may be taking on far more responsibility and increasing their sphere of influence.
Mature engineers tend to focus more on the opportunities and challenges available in a new position than they do about what they’ll be putting on their LinkedIn Profile. They know that any technical hiring manager worth their salt understands that every company uses different scales, and those managers won’t blindly assume that the candidate had been demoted mid-career if they see a title progression that looks somewhat backwards. They correctly focus on the engineer themselves and their innate talents, not on the details of their old business cards.
Should you worry about changing your title when making a move from one company to the next? No, you shouldn’t. At the end of the day, hiring managers for engineering positions are far more concerned about your technical chops than your title. Understanding your responsibilities and sphere of influence will be things that come out in the job interview. So, if you’re on the hunt for a new position, look for companies with a solid business model with a healthy and functioning team that will be taking on interesting challenges. Put minimal emphasis on the title you’ll bear once you work there, and focus more on how the position will allow you to develop your skills and knowledge. Those are the most valuable assets prized by any engineer, and by the managers who hire them.
8 thoughts on “Understanding Software Engineering Job Titles”
“Should you worry about changing your title when making a move from one company to the next?”
Considerably different title for same job/responsibility/position in hierarchy/whatnot => OK
(E.g. “developer” vs. “engineer”.)
Accepting a similar but “lower” title for the same job => Judgement call
(Including e.g. temporarily dropping a “senior” when moving to a company which proclaims to have higher standards.)
Inadvertently sliding down a step through misjudging the titles => not OK
(Including a dropping of “senior” when the employer has lied about or misjudged how high its standards are, but normally through different naming conventions, e.g. that one company has everyone as “developer” with a relatively more fine-grained modifier and the other divides into “developers” and “designers” with a relatively less fine-grained modifier.)