What seniority means for a software engineer? Is it familiarity with frameworks, libraries or something different? In this post, I will try to summarise my perspective on how it is changing for me. Got a lot of view during the last three years when I have lead or participated in a decent amount of interviews for engineering roles, including the C-level executives. Let state the obvious: fair and good hiring is super hard. During the hiring process, you try to assess the seniority of the candidate(and other qualities for sure) according to the company career ladder. As a reference, industry-respected and well-known ladder description can be used Google career ladder. If you haven’t had an opportunity to familiarise yourself with it, take the time and do so, it is definitely worth understanding. Google career ladder construction anchored in Google perfect team study. This post doesn’t attempt to mimic Google research but rather provide a starting point and raise curiosity. Excellent management is where the resulted outcome of the team is far greater than the pure sum of individual contributions.
Seniority levels
Seniority levels are usually a combination of technical “hard” skills and other skills collectively referred to as “soft” skills. Unfortunately, relatively few companies go beyond this level of explanation.
Junior level is characterised by a strong desire to learn new tools, frameworks and techniques. Often connected with black and white view on problems and when solving a task, junior developers can come up with a single possible solution or more with slight modifications. It is nothing wrong to be at that stage, and healthy teams often contain some junior developers as they bring fresh trends and passion to the teams. However, having more than 25% of junior developers in the team is challenging as they require more attention and slows the team down or affect the quality. Be careful with this mix.
Gaining seniority
Gaining seniority goes on a few axes – technical skills, context developer is using during the evaluation of possible solutions and ability to communicate effectively. Junior developer has limited technical skills, and his context is limited to code he is writing and communicates solely in terms of code, requirements or tickets. Context is a vital vehicle for guiding a developer in two remaining axes. As technical skills are growing number of the possible solution raises as well. Context can be divided but not limited to the following scopes:
Codebase
Limits the knowledge to the current codebase, used technologies and design principles and thinking in those low-level terms. This definition can be confusing as project codebase is involved every time as the ultimate source of truth but what differs is the level of abstraction. Developers are growing by operating bigger codebase and experience on different project codebase.
Development habits and practices
This area covers topics like where to apply which kind of tests. Where are the areas you can compromise if chasing time, and what are the real costs? Tech debt management. Essential features for long term supportability. Those items can be categorised under some risk management and damage control practices.
System design
Designing a system for performance, scalability, security and similar system-wide aspects. Defining thread zones and expected failure scenarios. Think in terms of consistency and ability to enforce those policies on the platform level. What can be handled on infrastructure level vs what is necessary to address in the application code?
Different mindset or roles
Understanding of other functions and associated mindsets of people participating in the development process (system engineers, quality assurance, machine learning engineers, project managers, etc.). What helps the best in this area is to try out the majority of those roles. Getting the role mindset will simplify communication during cross-team communication.
Software development life cycle
Ability to foresee and expect requirements which might not be implicitly obvious or stated in the desired functionality description. Understanding of product lifecycle stages starting from ideation till end-of-life. An item like supportability, troubleshooting etc. What helps in those aspects is to take the perspective of technical support personnel and think in terms of what-if. How difficult would it be to discover that component/feature X doesn’t work as expected.
Technology overview
Knowledge of technologies and alternatives gives you lego blocks for building a final solution architecture. This is especially important for the cloud-based product as you are trading a cost for a speed of delivery. Similarly, the same applies to programming languages. Those have specific features, design patterns etc.
Cross disciplines
This context is pretty similar to `Different mindset roles` with an only difference; it is focused on actual skills necessary in those roles and effects the tools have on team dynamics. Disciplines like development, operation, infrastructure, marketing and similar.
Cross-level and cross-department awareness
Understanding main objectives, areas of competence and levels of abstractions those people operate on. Unfortunately, even though role titles repeat competencies and responsibilities differs significantly between companies. That is what makes the execution different for each company and is one of the secret sauce of success. Effects are visible in accounting and balance sheets.
Management and leadership skills
Guide the team without command and control approach. Leading the change throughout the team, getting the buy in to support the change and move things forward.
Business domain
Understanding of industry you operate in helps you to drive better value for your customers by combining your technical abilities with domain knowledge.
Business models
Understanding how the business makes money on the product you build helps you to understand key aspects of the technical solution in terms of desired points of flexibility, scalability and cost management.
Wrap up
Knowledge and experiences in those scopes provide a better context for making decisions in the bigger picture and finding a more strategic solution for given conditions. Helps you to drive communication more effectively as you can think more like your counter-party and understand his point of view. Lastly, you should be able to come up with a plan of delivery iterations with a value-added in each iteration and mitigated risk.
The more senior you get on technical skills and proceed on the career ladder, the more the role start rely on your leadership skills. The vast amount of companies than forces people to manager roles but some (including Google, Facebook, etc.) allows to continue on technical track and label those positions as Principal or Staff Engineers. The role of those engineers is usually to improve the engineering culture and best practices of the teams apart from solving complex engineering tasks.
I neglected at least one aspect in my writing, the effect of personal characteristics and perspectives for particular roles. I am not going into those but instead refer to great Neil blog with people topologies
What’s the number one lesson you’ve learned since starting in tech as a junior developer? Tweet me @jak_sky and share your story.
Resources for further study
Team Topologies: Organizing Business and Technology Teams for Fast Flow
The Five Dysfunctions of a Team
Value Proposition Design: How to Create Products and Services Customers Want
If you like the content or have some experiences or questions don’t forget to leave a comment bellow and follow me on Twitter.
All about software development 