As you progress through your engineering career, your titles will change. Those titles are not standard across the industry, but operate under a handful of implicit definitions. We are sharing our internal definitions here. These are intended to help prospective employees by demonstrating what our internal standards are, guide current employees by making it explicit what is expected of them, and inform non-engineering team members by letting them understand the experience of their coworkers.
This progression system is neutral, meaning it applies to any engineering position (whether it’s software engineering, machine learning, operations, or anything else), and it explicitly includes management skills. It is smaller in scope than some other ones in the industry (lacking some intermediate steps), as it is optimized for reasonably sized companies (under 1000 employees).
<aside> 🎗️ Years of experience do not make a title. Furthermore, these are not titles. These are about what you do, not about how long you’ve been doing related things, or what your title is. They represent your progression and skill level. Our job postings specify what the expected progression level for the title is.
</aside>
A Junior Engineer (our definition includes “trainee” in this wider category) is expected to be able to perform a task if it is sufficiently well defined. This means that they need to be presented with the problem, the solution, and explained how the solution is intended to function. Once that’s done, they should be able to produce a working implementation of this solution.
While they are not expected to have all of the best practices in mind, they are intended to consistently check against our internal list of norms and policies, making sure that whatever they do is compliant with all of them.
They should be able to explain everything that they’re doing to a more experienced engineer, and they are expected to understand the nature of their work, but may miss out on the internal details of the prior art, or on some of the ramifications of their proposals.
They are expected to test their work at least manually, and dutifully apply any changes requested by more experienced coworkers. They are expected to continuously improve and learn about their tools and everything (including non-technical aspects) surrounding what they do. A big part of the job is to ask questions, especially when the answer is not already documented, or isn’t sufficiently clear.
A Confirmed Engineer is expected to be able to implement a solution. This means that they need to be presented with the problem, and the expected solution, which they will then find an appropriate implementation for.
They are expected to be familiar with the best practices of their field, and to follow them, unless our internal list of norms and policies contradicts them. Their solutions should be functional and follow these guidelines on the first attempt, but may miss out on better ways of accomplishing the task at hand.
They should be able to explain everything that they do to their peers, and are expected to understand the nature of their work, as well as the internal details of the prior art, while potentially missing some of the ramifications of their proposals.
They are expected to test their work, as well as those of the Junior Engineers, suggesting improvements where they see them, and applying improvements that have been suggested to them. They are expected to be minimally familiar with their tools and everything (including non-technical aspects) surrounding what they do.
A team lead is a management position between a Confirmed Engineer and a Senior Engineer. They help organize their team by delegating tasks to the best candidates, collaborating with the Product Owner, participating in Sprint Planning, and act as the point of contact for Engineering Managers.
Due to the nature of their position, they must also be able to explain the work of their team members to other engineers, as well as efficiently communicate to non-technical staff. They’re also expected to have a greater understanding of the product, both technically and non-technically, as it’s a requirement for being able to delegate efficiently. They can formulate a roadmap for their team.
They are expected to spend about half of their time acting as an individual contributor and half of their time split between managing and helping their team.
A Senior Engineer is a problem-solver. When presented with a problem, they should be able to immediately conceive of a potential solution, as well as a way to implement it. It may not be an optimal solution, but it should be 80% towards one.
They are expected to be familiar with the best practices of their field, but also understand why those practices are the best practices, and thus also know when to question or bypass them. When their solutions do not follow a best practice or a policy, they should be able to justify it technically, which should sometimes lead to a new norm or policy, or to an existing one being amended.