At Intempt, we focus on technical ability, technical leadership, and teamwork. These go into the mix when we figure out our leveling within the engineering team.
Six Intempt Engineering Levels (hat tip to Google)
- Associate Software Engineer (new grad, 0- 1+ years of experience) —— Expected to fix bugs and build parts of a micro-service (features) within a single repo without day to day guidance.
- Software Engineer (most new hires start here, 2+ years of experience) —— Expected to build a micro-service (typically a single repo) with architectural guidance and minimal day to day guidance.
- Senior Software Engineer (equivalent to Manager I, challenging to be promoted above this level) —— Expected to architect and build a micro-service, like our Analytics engine or build a new web app from scratch (like our console), correctly, without much guidance.
- Staff Software Engineer (equivalent to Manager II, difficult-to-impossible to be promoted above this level) —— Expected to Architect several a new micro-services correctly for scale, including open source technology selection, so understand how Analytics is built standalone and how it is a shared service to Customer Data Platform & our Experiences engine, for example.
- Senior Staff Software Engineer (equivalent to Senior Manager) —— Expected to Architect a major portion of the platform (multiple micro-services) for the future (10-100x scale) so the architect and build multiple Platform services such as Sources, Segmentation, ML and Campaign and define how they all work together and separately.
- Principal Engineer (equivalent to Director) ——Everything above and expected to understand competitive platform software and fundamentally differentiate at the platform/infrastructure level without guidance. And when to cooperate with competitors for mixed deployments. At the highest level of this grade, you generate original ideas to bolster the platform from future market movements and make it harder for vendors to compete.
So how do you move between levels? Let's focus on the basic unit of productivity, the Pull Request.
The goal of an engineer is to get a LGTM (“looks good to me”) on a significant PR. This is an approval to ship from an engineer on the same level or preferably more senior.
Some metrics to consider as you look at your PR's over time:
- Number of comments: How many comments do I get on average?
- How often do I PR: How often do I deploy code to our codebase? More often is generally better.
- Review time: How much time so I spend incorporating comments?
- Lines of code: How much code do I contribute? More is not necessarily better. Being overly succinct isn't necessarily good (from a readability perspective) either. Compilers do their job rather well these days.
- Working time: How long do I spend writing code before I PR?