Ask HN: Favourite definition of seniority of software engineers?
I'm pulling together a list of criteria for the various levels of software engineers. I know some are public. What are the public definitions that you like the most/feel are accurate with your experience?
6 comments
[ 1.7 ms ] story [ 33.1 ms ] threadAn increase in seniority comes with (A) a decrease in hands-on time with technical problems and (B) an increase in time spent on project management, team organization, and people problems.
None the less, there are some possibly interesting resources regarding levels at Honeycomb [1], Netflix [2], and Gitlab [3]. There's a whole book if you're going to venture into "staff" [4]. Last but not least, don't forget the Peter Principle [5].
[1] https://www.honeycomb.io/blog/engineering-levels-at-honeycom...
[2] https://blog.pragmaticengineer.com/netflix-levels/
[3] https://about.gitlab.com/job-families/engineering/developmen...
[4] https://staffeng.com/guides/staff-archetypes
[5] https://en.wikipedia.org/wiki/Peter_principle
Does the peter principle assume a person stops learning? On the surface, yes. And if learning leads to skills, maybe we could also consider success in different jobs as a combination of both skill and motivation. This would highlight a couple of the common, real-world problems I see when engineers "rise" up the ladder:
1. A first problem is many senior roles require new organization and leadership abilities, thus the core of the Peter Principle. (skill)
2. The second is that absent careful thinking and goals, many engineers will seek arbitrary advancement only to find their ability to succeed disappearing when those new skills aren't as fun/engaging/fulfilling. (motivation)