Software Engineering Levels

For many software engineers, SE job titles hold a special place. No other topic elicits a more passionate response than when an engineer thinks that their ranking in the pecking order is threatened by an unworthy usurper in their company. The pattern is the same, whether it be a 1000+ tech drone corporate or small tight-knit startup.

Although initially used to define various steps in the career ladder ¹ which meant more prestige from the colleagues and more importantly, better compensation from the employer - the ranks have warped into a pissing contest between new developers in the industry. The way I like to look at it is that the ranks are purely indicative of the level of impact, and the breadth of responsibility that any engineering individual in the company has. Unlike popular opinion, I don't think it's necessarily tied to experience either - I have seen engineers with < 2 years of experience handling complex architectural problems and conversely seen someone with > 10 years of experience in the industry struggling with basic programming concepts. There's also the matter of company size, a mid level at a large company might be a senior at a small company and vice versa. The career progression paths are different in every company and where you might lie based on that should also be taken into account.

For someone who has been coding since the age of 13 and has had various jobs at different levels in a professional setting for the past five years, I felt like now was the time to put in writing my thoughts on what constitutes developers at various levels. It is worth noting however that whatever you read here isn't definitive, and as always factors outside of technical and soft skills should be taken into account.

Junior Software Engineer

This is someone who's just tasted the wonderful life of what it means to make machines do mans bidding. More often than not, people that are put in this category are either fresh out of university with a degree that had some programming background or have just graduated from an academy, or an institute specializing in teaching people how to code.

In my opinion, such candidates are the lifeblood of any organisation, and they should be given space, time and most importantly mentorship, to grow. Usually the expectations for people in this role are:

• Write code. As simple as that. As a junior, the expectations are not multi dimensional, and the company would thank you for just writing code and getting s*&$ done! You might be good at leetcode and blazingly fast at writing linkedlist implementations, but if you can't write proper javascript and css as a frontend engineer, you're already on a sinking ship.

• Network and be open to feedback. Perhaps the most important skill of them all when you're just starting is to always be open to feedback from peers, whether it be via pull requests submitted at work or via a mentorship sessions with someone with a bit more experience. Another important professional goal should be to network with as many people as possible within the industry. This can involve going to meetups, tech fairs, conferences, hackathons etc. Programming by nature attracts social recluses, so going to events like this can provide a safe environment to meet new people in the industry without the undue pressure of an alternative social setting.

• Learn various auxiliary system. Professional programming isn't simply writing code, it involves using version control systems, dealing with frameworks, reading APIs and reasoning about the system from them, working with databases etc. No one would expect you to be an expert in these systems, but knowing your way around it is almost essential part of the role. Fortunately, any good company will be willing to spend time and mentorship hours to coach you on any of those topics if you'ev never done them before.

• Fundamentals and algorithms are good, but pick a modern framework (and if possible, stick with it). As the saying goes, frameworks come and go, but the logic never changes (okay yes, I just made that up). It's hardly a secret that there always seems to be a new framework to achieve a result, this is especially true of frontend - but it's worth investing and picking up one of the popular framework to gain deep knowledge in, especially for juniors. I picked up VueJs and Spring boot as my front end and backend frameworks of choice and have never looked back. It was one of the best decisions I made as a junior.

Mid level Software Engineer

These are the underdogs of any dev shop. Almost always underappreciated but are the ones making sure the product guys are happy with the sprint velocity. Humor aside, mid level engineers ensure the rhythmic hum of new features being churned and priority bugs being squashed withing the organisation. The people that fit in this role usually have following expectations:

• Working autonomously or with minimal direction. A solid mid level engineer, after an initial period of acclimatisation is in tune with the product that the company is selling is able to pick up technically challenging or unassigned work without little to no effort. They may still require some guidance here and there, but for the most part the company, and their peers can be confident that they will always deliver on their assigned work.

• Mentoring or showing the ropes to juniors. Often companies will expect mid level engineers to be showing the ropes to interns and junior software engineers - this can mean many things, however, usually involves pairing with them through onboarding and making sure onboarding docs are up to date, guiding them on fixing issues with individual components and generally being a validation checkpoint for their development queries.

• Comfortable in making component and micro level architectural decisions. This part of mid level engineer roles, overlaps with a senior engineer/solution architects role. As a mid level engineer you're also expected autonomously make micro level code and drive technical decisions within a small 2-3 team pod. Quite frankly, most companies won't expect it but in my opinion if someone is truly looking to breach into the senior engineer and then perhaps technical leadership ladder this is an essential skill.

Senior Software Engineer

People in these positions are usually regarded as the influencers and drivers of technical direction in a given stack/project domain for the company. Routine expectations for people in such roles are:

• Deep knowledge of their stack and company's product domain. Senior engineers are usually expected to be the go to authority on complex technical questions and architectural design decisions. They're expected to know their technical domain very well, including any quirks, and are expected to use that knowledge to solve complex product and build challenges.

• Technical stewardship. Most companies expect senior engineers to be the stewards of their chosen tech stack. This can manifest in various ways, for example, some are champions of their industry and are regularly given talks about a particular programming concept or tool. Others, tend to do things more privately and are consistently experimenting with better and smarter way to build systems and improve business outcomes within the company. This requires people in senior engineering position to be constantly updating their skills.

• Long term focus. This probably the most underappreciated part of a senior engineers roles, but which I think is what really differentiates a true senior engineer from the lot. A senior engineer is expected to always prioritise maintainability/extensibility over everything. This is part of their programming DNA, and this is what allows them to dismiss the new fancy framework of the season, or the next -killer.

Communication

Communication is such an essential skill for engineers at all levels, so I decided to dedicate a whole section to it. Good communication skills are hard to quantify but very easy to identify. More often than not, technical and project management, inside a company would rather have engineers that can communicate but produce marginally less output over engineers that are rockstars but lack the desired communication skills. This is not universal, but it is definitely the trend.

For entry level/junior engineers it's important to be to consistently ask for feedback and articulate why the code they added/changed was done in the way it did.

For mid level engineers, it's important to be able communicate with juniors on the team as well as be able to document design decisions made over the course of delivering product features.

For senior engineers and above it is even more critical, as a big part of their job is to communicate their ideas and have them percolate through various teams inside the development org.

Why leave the rest

I understand that an engineering org can, and mostly is, made up of other varieties of engineers such as intern or graduate/entry level engineers, technical analysts, software architects, tech leads, devops ninja etc etc. This is post is not aimed at them and sometimes a lot of their skills will overlap with developers. I might do a follow up post in the future that targets people working in cross-cutting development roles.

References

1. Software Engineering Job Titles
2. On Being A Senior Engineer

This article was also posted on my blog here