Recently there has been more reconsideration of what 'levels' look like for a software engineer. Where there was formerly more homogeneity across development work, there is recently a huge range of specialization. These many areas of specialty challenge the classical idea of seniority, as a very senior-skilled engineer may lack fluency or capability with a pivotal practice that has been nearly mastered by an otherwise-junior developer. Conversely, junior developers may overestimate their their vision under the study of average teachers.
In an ideal sense, and one that is humanly-impractical, there could be a method of scoring and totaling one's abilities across all of these pivotal practice areas, and totaling and aggregate that equates to skill level. That is a trend toward excessive accounting, or an AD&D-like role-playing schema for one's life.
Today, at least, that is not our culture. Yet it is good to remember that Amazon and many other large firms have identified a value with interviewing and reviewing using carefully crafted scoring systems. 'Scout badges' may yet return, if this is a trend.
This page may move to be a reflection of the structure that @sarah_edo setup here. My own history with roles and levels will get worked into that. In order to try for a general format that can guide ladders at any company, here we will unfold some of a rubric.
Deeply granular assessments are more ideal for differentiating areas of strength, and giving very targeted mentorship and support. The same can also cause overload.
A simplified version of skills assessment usually covers these four areas:
- tech quality
- collaboration
- execution
- org quality
Any organization in a company can reuse these by relating 'tech' quality to any use of tools to speed up workflow and delivery. All code is essentially tools for automation.
Above all else, the assessment of career growth should mirror the assessment during Interviewing, including personal/psychological makeup.
(compare vs a role like "Principle/Staff Engineer")
- Designing and Implementing the solution to a large software problem
- Modeling Data for Different Use Cases
- High Level understanding of the entire technical system/architecture
- Architecture of Web Interfaces
- Creating and Coding Automated Tests
- Owning and Debugging Production Issues
- Pressure Testing Qualitative Work
- Debugging, tracing, and reverse engineering
- "you have logs or shut the fuck up" -SGUG
- Solving a Narrowly Defined Problem
- How to Ask a Good Question by StackOverflow.
- Cutting Through Complexity
- Implementing Algorithms and Data Structures
- Building Modular/Testable Components
- Functional Programming
- Object Oriented Programming
- Understanding Type Systems
- Understanding Code
- Observability, Instrumentation, and Performance
- Building and Using Your Work Process
- The Unix interface
- Designing and Developing Tools to Manage Cloud Infrastructure
- Administering Databases
- Considering the User Experience (HCI)
- Designing API for Public Use
- Behavioral Instrumentation
- Pulling in Help and Collecting Advice
- Improving a Team's Performance by Reflecting on Outcomes
- Coaching your Team Members
- Distributed Teams and remote hygiene
An interesting article discussing many roles and their function.
As well a list of books on communicating at the level of a manager.