editione1.0.1
Updated August 7, 2023It’s a question that’s been debated for decades within the software community—what qualities separate a junior engineer from a senior engineer? In this section, we’ll take a closer look at this question and help you understand why the answers vary so greatly. We’ll also explore a few topics that are absolutely critical if you’re working towards a promotion to a senior role. By the end of this section, you should have a concrete idea of the differences between a junior and senior engineer. Let’s get started.
If you were to pull up your preferred search engine, enter the query “what is a senior software engineer?”, and hit enter, you’d be presented with hundreds of different explanations of what it means to be a senior software engineer.
It’s interesting that as programmers, we work in an industry that has self-organized around standards and protocols such as TCP/IP, HTTP, HTML, IMAP, SMTP, and many others that play an important role in a connected society. These standards provide a basis for which we all agree on something—a mutual understanding. And yet the truth is that there are so many different interpretations on how to define a senior engineer precisely because there is no standard definition for what is actually required in order to call yourself one.
The software industry is still very young when you look at it in the context of history. While other industries have formed consensus on what standard requirements should be met in order to do business or practice an occupation, we’re still learning the best way to deliver software reliably and efficiently. You don’t have to pass a licensing exam in order to write software professionally, you just need to demonstrate that you know enough about programming to pass an interview.
The reason for this ambiguity is partly because of the diverse opportunities within our industry. As programmers, we can work for small seed-stage startups all the way up to Fortune 500 public companies, and across almost every industry—energy, healthcare, finance, entertainment, and education, to name a few. So, when you really think about it, how should we standardize a common definition? A senior engineer’s role and responsibilities at a seed-stage SaaS startup are vastly different from those at a public healthcare corporation, hence we see different interpretations for what it actually means to be senior.
Each business needs to form their own organizational structure around what works best for them, so it makes sense that roles and responsibilities are unique to each enterprise. Yet people try to compare apples to oranges all the time when it comes to debating the characteristics that make up a senior engineering role. In fact, what some people fail to realize is that the word “senior” has multiple meanings here, and each organization interprets the title differently.
Some companies interpret seniority as a reflection of a software engineer’s actual years of experience at a company or in an industry. Certain industries are complex enough that it takes years to learn the nuances of a company’s product suite and how it solves a customer’s pain points. A software engineer who’s spent years building a complex product carries vast amounts of domain knowledge with them, and they understand the product and the industry better than anyone else.
While these engineers typically have strong technical skills, they may not always be the most technically skilled on their team, yet they still get promoted. They may bring domain knowledge and experience delivering software in the industry, which some companies value more than pure technical ability.
important You tend to see years of experience valued in highly regulated industries where domain expertise is more valuable than pure technical abilities, such as aerospace, telecommunications, transportation, healthcare, energy, and certain financial businesses.
On the other hand, some companies interpret seniority as a reflection of a software engineer’s technical abilities. While not always the case, businesses in a growth phase tend to hire or promote from within based on one’s technical abilities. This is because these companies have validated their business model and are evolving from a startup into an enterprise. They need to scale their codebase, team, and software development processes as they cross the chasm from an early adopter product to a mass-market solution.
Growth companies need strong technical people to lead the charge as they refactor, rewrite, and scale their systems to handle more demand. Domain knowledge is valuable in these cases, but some of the challenges to be solved are purely technical, so companies may hire and promote from within the candidates with the strongest technical abilities, even if those people have less years of experience than others. This is where it pays to specialize in specific technologies, because you may be able to find companies in a growth phase that are looking to hire for strong technical skills in one or two specific technologies, regardless of whether you have industry experience. For example, a fast-growing security company may need to hire engineers with deep knowledge in cryptography, or a regional internet service provider that’s looking to expand into a new market may be looking for network engineering experts.
important You tend to see this more in startups and fast-growing technology companies. If a business is focused on scaling at all costs, pure technical ability is more valuable than domain expertise.
Most companies combine both interpretations and look for well-rounded software engineers that have both years of experience and strong technical abilities. They view seniority on a spectrum, with years of experience and technical abilities at either extreme. Their ideal candidates would bring both domain expertise and technical skills, but they may make exceptions if they come across a candidate that skews towards one or the other.
Now that we’ve uncovered the different interpretations of what it means to be senior, let’s look into some skills required by all senior programmers, regardless of whether the title is based on years of experience or technical knowledge.
When you’re first starting out in your programming career, you’ll be fixing bugs and extending existing features to add new functionality. Most of what you’ll be working on will be determined by a product manager, your engineering manager, or a senior engineer. It’ll be up to them to determine most of the functional and technical requirements, and it’ll be your job to implement a working solution.
As you grow into a senior role, you’ll be faced with more ambiguity in the problems that you need to solve. There won’t always be a straightforward answer, and oftentimes there will be a number of ways in which you could solve a problem. It’ll be up to you to weigh the trade-offs and determine the best path forward, which may not always be the ideal technical solution.
Senior engineers are often asked to solve difficult technical problems when there isn’t always a good understanding about how to get there, such as keeping a user’s shopping cart updated in real time across both web and mobile devices. It’s up to the senior engineer to break the problem down into smaller, more manageable pieces, determine dependencies between the pieces, and put together a plan for building a solution. Junior engineers, on the other hand, often have a known path set out in front of them and are tasked with working towards a goal, such as making sure orders are processed successfully and inventory numbers are updated accordingly.
Dealing with ambiguity is what sets a senior engineer apart from a junior engineer. This partly comes down to experience, but it also has to do with problem-solving skills, creativity, collaboration, and good communication. It takes all of these skills to keep projects moving forward and finishing on time, and senior engineers learn how to leverage them in order to reduce ambiguity.
In addition to being able to cut through ambiguity to deliver results, senior engineers are expected to be accountable to others and themselves. They are responsible for project timelines and ensuring that the features shipped to production meet all of the project’s requirements.
Junior engineers sometimes blame the quality assurance (QA) engineers or other devs who reviewed their pull requests for not finding a bug in their code, rather than accepting responsibility for it being there in the first place. Senior engineers, on the other hand, accept that responsibility and take full blame for letting bugs slip through, even the ones that aren’t caught by peer reviews and QA engineers.
When senior engineers make mistakes, they treat their peers as teammates, rather than adversaries. Being able to accept responsibility for your mistakes and work with your team to identify and fix the root cause is a sign of maturity, and it shows that you’re ready for a senior role.
Managing time effectively is one of the common traits among senior software engineers, and it’s also one of the hardest skills. As you write more code and build up more domain knowledge, you’ll start to become an integral part of your team. You’ll become the expert on certain features and areas of the codebase, and people will come to you with questions about how something works or if it’s possible to extend something you wrote with new functionality. You’ll spend more time tracking down bugs, planning new projects, building out feature specifications, and possibly even helping to interview candidates to join your team.
Time management gets harder the more senior you get. Your team will become increasingly reliant on you to keep things moving, so it’s important to get things done while not wasting your time.
As a junior engineer, it’s good to be generous with your time, because anything you work on will help you learn. But as you prepare for a senior role, you’ll need to learn to be careful with your time because it’s your most limited resource. Senior engineers know how to work smarter, not harder, because they know that using their time wisely gives them leverage.
They may spend a day or a week planning, without writing a single line of code, because they know that getting the solution right on paper will save them weeks of refactoring later in the project if the design needs to be changed.
They know when to allocate their time to helping others, because sometimes helping unblock a coworker raises the entire team’s throughput.
They know when it’s important to document a critical piece of the system, even if it takes them hours to type it all up, because it’s worth spending the time to share the knowledge.
They know how to find chunks of time in their day for deep focus and writing code, even if that means declining meetings or blocking off time on their calendar.
They timebox their work. They know that it’s better to ask for help or move to a different task than to spend too much time running in circles.
The best programmers understand how important their time is and will optimize their tasks and focus on those that will have the greatest impact based on the time constraints.
Programming is naturally a detail-oriented task. Take any programming language’s syntax for example—you could have a codebase with hundreds of thousands of lines performing complex data processing, but if you misplace one semicolon or forget to close a parenthesis somewhere, your program will grind to a halt. Even worse, your logic may be flawed even though the syntax is correct, which will lead to frustrating nights trying to figure out why your program compiles but doesn’t behave the way you expect it to.
Almost every aspect of delivering software requires focusing on details—things like defining requirements, reading other people’s code, writing correct logic, implementing thorough error handling, and analyzing logs and other structured data.
As professional programmers, we’re expected to prototype solutions and write applications to solve customer pain points. But it’s not enough to focus only on the default use cases and ignore error handling or how our users interact with our programs. Good engineers try to anticipate every way in which a program can fail, and then work to put safeguards in place to prevent those scenarios from happening.
And they’re not just detailed in the code they write. They bring attention to detail throughout the software development process. They pick apart the technical requirements and clarify any ambiguity, because they know that well-defined specifications aid them when it comes time to handle edge cases in their code.
How are senior software engineers detail-oriented?
They have an ability to find gaps in the requirements and ask the right questions to fill those gaps.
They tend to be diligent about keeping their codebase clean and organized.
They read other people’s code, sometimes more than once, to understand what it’s doing. Then, they try to figure out ways in which it can fail.
They are meticulous about covering all the bases, whether it’s through test coverage, input validation, or handling edge cases. The more scenarios their code handles, the less chance it has to fail.
They know how important good documentation can be and will find time to write it, even if it’s not the most glamorous part of the job.
High-quality software requires a high attention to detail, not just in the code but in the entire software development life cycle.
It takes persistence, determination, and many years in order to perfect a craft, but in the case of Jiro Ono, a sushi chef made famous by the documentary film Jiro Dreams of Sushi, he spent his entire life in pursuit of perfection.
Always looking to improve, Jiro worked hard every day to improve all aspects of his craft, from sourcing better ingredients, to preparing his dishes, to delighting his customers with the highest quality sushi. He was so determined to deliver the best experience possible that he fixated on every aspect of the meal, even changing the orientation of the sushi on the plate if the customer was right- or left-handed.
These small improvements compounded over the years, and Jiro’s small 10-seat restaurant located in a Tokyo subway station, Sukiyabashi Jiro, became the first sushi restaurant in the world to receive three Michelin stars.
Although programming requires a very different set of skills than making sushi, writing software is also viewed as a craft, and as programmers, we are always looking to improve our coding skills.
Engineering excellence is a means to an end, not an end goal in itself. It is the relentless pursuit to raise the bar in terms of the quality of our software and the speed at which we can deliver it to users. Senior engineers continuously strive towards engineering excellence to improve the processes by which their team delivers software. They identify barriers and obstacles that prevent themselves and their team from doing their best work, and then work to remove those barriers in order to unlock higher quality and greater throughput for the team as a whole. In doing so, the goal is to delight users with the best experience possible.
There’s a lot that has been written about teamwork, and for good reason. When you have a group of people all working towards a common goal, you can achieve great things. Each individual member on the team brings with them a unique set of skills, and when a team is able to leverage the skills from one of their team members, everyone benefits.
Senior software engineers recognize that shipping software is a team sport. While programming may feel like an individual activity when you’re deep in the code, developers rely on one another to review their code, answer questions, share knowledge, and teach each other.
When software developers work together, they can achieve so much more than what each individual could accomplish on their own. When they build off each other’s work, fix each other’s bugs, and share their knowledge, a team becomes greater than the sum of its parts.
A senior engineer recognizes the importance of the team, and they identify and complete tasks that benefit the team, even if the work isn’t planned or assigned to them. They understand that sometimes being senior means taking on the mundane tasks that no one else wants to do, because it will help unblock others to complete more work. Their focus is always a team-first approach, and they strive to lift up all members of their team because they know that when it comes to software, we all share the same responsibility to keep the systems running and deliver as much value to our users as possible.
Senior engineers recognize that the team consists of more people than just other software engineers. Test engineers, product and project managers, product owners, scrum masters, designers, and technical writers can all be a part of the same team or business unit. Just because someone doesn’t write code doesn’t mean they’re not part of the team, and senior engineers work with everyone to achieve the team’s goals.
Senior engineers look for opportunities to mentor junior engineers, help them develop their coding skills, and teach them problem-solving techniques. We all start out as junior engineers when we begin our careers, and senior engineers are able to empathize with the younger members of the team and help them work through problems collaboratively when they notice someone is stuck or unsure of which direction to go.
And finally, senior engineers understand that in some cases, sacrificing their own productivity in order to unblock or enable other developers’ productivity is time well spent. They may spend a day without coding while they work through requirements for a project because they know it will enable the rest of their team to work quickly with clear instructions. They view productivity in terms of the whole team, rather than just themselves, and sometimes that means working through others or spending more time upfront in order to enable their team members to move faster in the future.
As companies hire, grow, and promote from within, they often need to make decisions about the requirements and responsibilities for each role, including each individual’s salary compensation. Job levels are a tool that many organizations use to standardize these decisions and explicitly define and document the responsibility level and expectations for each role at a company. Job levels are typically associated with pay bands or salary ranges for each level, and different companies structure their levels differently depending on their unique organizational needs.
So, why do companies utilize job levels?
Job levels allow organizations to be strategic with their hiring decisions and bring more consistency to the hiring process. Levels provide a helpful framework for how a company should hire, promote, and retain their talent, as well as providing a way to highlight specific areas for improvement, while developing their employees along their career growth trajectories. Additionally, job levels bring fairness and transparency to promotion decisions by providing a structured approach to identifying when an employee is ready to move to the next level with a promotion.
So, how can you use your company’s job levels to leverage a promotion?
Whether you like it or not, climbing the corporate ladder is a game. And the job levels provide an even playing field for you and your peers. Fortunately, these job levels also lay out the rules of the game for everyone to see, so the better you understand the rules of the game, the better you can use them to your advantage.
First off, if your manager or HR department hasn’t already provided you with your company’s job level matrix, you should ask for one. Most larger companies should have a job-leveling framework in place, but not all do. If you’re working at a smaller company or a startup, they may not have one, but it’s still good to ask. At the very least, it will show your manager that you’re motivated to grow your career and work your way up the org chart, and you might even convince them to create one.
Once you have a job level matrix, you’ll be able to see exactly what is expected of you in your current role. You’ll be able to see your current responsibilities and identify areas that you know you need to improve. Even better, you can also see what skills and responsibilities are expected for more senior roles, and it provides a blueprint for exactly what you should be working on in order to jump to the next level.
So, let’s look at what a common job level matrix looks like for programmers. It’s valuable to view a junior role and a senior role side-by-side so you can compare and contrast the differences in impact and responsibilities. Although it may already be apparent, it’s important to note that there is an assumption that these levels are cumulative, meaning that a senior programmer is expected to meet all the criteria in their current level, in addition to all the criteria and responsibilities in the lower levels as well. Keep this in mind as you’re working towards your promotion, because you need to build a solid foundation in your current level before you can work on the responsibilities of the next level.
Here’s what a common job level matrix for junior and senior programmers looks like.
| Junior Programmer | Senior Programmer | |
|---|---|---|
| Job Scope | Performs moderately complex problem solving with guidance and assistance. Is able to follow functional specifications for new features. Primarily involved in implementing systems that others have designed. Expected to spend majority of time learning the system and software development best practices. | Performs complex programming tasks, often without guidance or assistance. Has solid understanding of the impact of their code on the team’s infrastructure. Has a strong understanding of how the different components of the system fit together. Is able to write thorough specifications for new features. Primarily involved in designing systems that they and others will implement. In-depth understanding of software development best practices. |
| Knowledge | Demonstrates solid understanding of programming fundamentals (data structures, object-oriented design, algorithm complexity). Has strong knowledge in their core area of the tech stack (programming language). Has general understanding of the components that make up the overall system. | Is highly competent in one or more areas of the tech stack (multiple programming languages). Can design a modular solution to medium and large problems. Possesses deep understanding of how the different components in the system interact with one another |
| Communication Skills | Communicates effectively in a number of scenarios: Code reviews, one-on-one conversations, small and large groups, management. | Is able to discuss technical trade-offs and alternatives in a rational and impartial manner. Has the ability to accept criticism of their designs and iterate based on feedback from others. Knows when to escalate issues. |
| Ownership | Contributes code that meets specifications. Troubleshoots issues and fixes defects in the codebase. Reviews code written by their peer. Contributes to documentation. | Identifies, proposes, and leads discussions that address problems impacting the team. Admits quickly to mistakes and works quickly to resolve them. Strives to learn from their own failures and failures of others. |
| Judgment | Offers their perspective during planning and design reviews. Proactively shares status updates with project stakeholders. | Is able to accurately estimate the amount of effort or complexity required by each task. Plans out work to ensure tasks are delivered on schedule. Proactively raises concerns with project stakeholders to ensure projects are delivered on schedule. |
| Character | Demonstrates initiative and an eagerness to learn. May provide mentorship to interns and peers. | Demonstrates initiative and a willingness to mentor others without being asked. Offers assistance outside of their own tasks when needed. Provides guidance to interns and junior level developers. Delivers constructive criticism when asked for feedback. |
Table: Job level matrix for programmers.
This is meant to serve as an example job level matrix that you would find in any engineering organization. Your company’s job levels may differ from the ones presented here, but the general idea will be the same. Your job as a developer is to identify which areas you feel you meet the requirements for, and which skills you know you are lacking. Once you’ve identified each category and where you stand, you have a blueprint for exactly what you need to work on in order to jump to the next level.
You may feel like you already possess certain skills or meet the requirements for the senior developer level, and that’s great! But remember that to be eligible for a promotion from one level to the next, you must demonstrate a proven track record of meeting all the requirements in the job level for your current role, plus some or all of the requirements in the next level. Only once you’ve proven you can handle the responsibilities of the next role will you be considered for a promotion to a senior engineer.
And remember, it doesn’t always have to do with how long you’ve been coding or how long you’ve been with your employer. The job levels are meant to provide an even playing field, and it’s entirely possible that someone with fewer years of experience will get promoted before someone who has been working at the company and coding longer.
Additionally, getting promoted to a senior developer role is not just about a change in your title. As you can see in the job level matrix, moving up to a higher level involves a broader set of responsibilities and more trust that you are capable of solving complex problems and that you always put your team’s interests before your own. In many cases, this also means there is more pressure for you to perform and deliver results on time. A senior role brings increased accountability along with more ambiguity in how to achieve your expected outcomes.
When it comes time for your annual review, it’ll be significantly easier to ask for a promotion to a senior role if you’re able to demonstrate that you consistently meet all the requirements in the job level matrix. One of the first things your manager will do is compare your past performance to the traits laid out in the senior job level matrix. And any requirements you haven’t met will immediately jump out as you’re being considered for the promotion.
Hopefully, you’ve learned enough to put yourself on the path to success. You should now have a better understanding of what you need in order to work towards that senior role, but it’s important to realize that it won’t happen overnight. The journey to becoming a senior developer takes years and requires a tremendous amount of discipline, hard work, and most importantly, constant learning. You are a student of the craft, and you will continue to learn throughout your career.
While becoming a senior programmer may be your goal, it should not be your destination. You should always be pushing yourself for continuous improvement. If anything, your learning will accelerate as you progress in your career, because you’ll be building on the foundation you will lay in these next few years. You’ll start to see how all the puzzle pieces fit together, and you’ll begin to design, influence, and engineer complex systems. You’re building a strong foundation today so that you can solve your customer’s toughest problems in the years ahead.
The Differences Between a Junior, Mid-Level, and Senior Developer (betterprogramming.pub)
Programmer Competency Matrix (sijinjoseph.com)
Job Titles and Levels: What Every Software Engineer Needs to Know (holloway.com)
Software Engineering Levels (dev.to/shavz)
Software Engineer Qualification Levels: Junior, Middle, and Senior (altexsoft.com)
Have you ever sat in a room and felt like you weren’t smart enough to be there? Maybe the conversation moved too quickly for you to follow, or perhaps your coworkers debated a topic you weren’t familiar with. It’s an uncomfortable feeling that every programmer experiences at some point in their career. When you start to doubt your own abilities and feel insufficient at your job, you’re experiencing impostor feelings.