What's The Difference Between Junior And Senior Engineers?

What's The Difference Between Junior And Senior Engineers?
Post Author: Aaron Decker | Just realized gen Z doesn't even know what Austin Powers is...
Date published: March 04, 2020

Lately I've heard a lot of developers joking about the term "Senior Engineer". On a recent episode of JavaScript Jabber Charles Max Wood said that he was first called a "Senior Engineer" after about a year and a half of professional work because his consulting company wanted to bill him at a higher rate!

So with that kind of title inflation going on it probably doesn't mean anything other than somebody is not completely green.

What Should "Senior" Mean?

To me, the term "Senior" should mean you are talking about a developer who is capable of building and shipping a small complete working piece of software by themselves.

In a larger system maybe that means a senior developer can design, build, and ship a big feature. Or perhaps on a very big system it means a senior developer can design and build a small feature that touches many parts of system and coordinate with many teams to ensure everything goes smoothly.

I think the capability of a "Senior" level developer is relative to the size of the project you are talking about.

What does it mean to "Ship A Product" or "Ship A Feature"?

I'm talking about being able to design, code, launch, and support a piece of software. With a feature it means the same thing, but just as a part of a larger system.

In big companies you might be surprised to see how specialized people are. They might understand the design and components of only a small piece of an enormous system and have 5 years experience just doing that one thing.

In small companies it's very different. At my first professional software job I was responsible for basically building the entirety of a small product with advice and mentorship from my boss. So months into my first full time programming job I was in a sense "leading" development of a project in that I made a lot of decisions (and mistakes) but I was generally the only developer programming on it at that point. But I don't think I was a "senior" engineer by any means.

At the end of 2 years of doing this, I felt very confident that I could build software and make the decisions required to ship something that worked.

Then I went to a startup and worked on some very high scale applications doing support and learned a ton about support and reliability and high traffic situations and I realized how much other stuff there was to learn.

At that point I had 3 years of experience working on varied projects and I really was maybe "senior" in the sense that I could handle shipping serious code by myself. I had built software and seen the outcome of my decisions and learned from mistakes and assumptions over time, which is really the key experience I think that makes all of the difference.

What Should a "Junior" Developer Be Able To Do?

When starting off as a programmer you can look back every few months at old code you wrote and see amazing progress. The learning curve is so steep and there is so much knowledge you have to absorb and employ that the pace of progress can be unbelievable.

This goes on for years.

Given this learning curve, it's hard to pin down what a "Junior" developer is. My thinking is that a junior developer is somebody that can work on a small "feature" (one component of an application) with moderate guidance from more senior staff .

A Junior developer should be able to take a design document from a more senior member of a team and turn it into working part of a larger application. I think at some point even a "Junior" developer should be able to ship relatively small features by themselves. I don't think that a Junior developer should be able to ship large features or entire applications (even small ones) by themselves.

Are bootcamp grads "Junior Developers"?

I think it depends. Let be realistic here: unfortunately it often takes a year or two to even get to the point where a developer can effectively work on application features that are part of a larger more complicated system without heavy guidance from a more senior developer. Most bootcamps are just plain not getting their graduates to this point in my opinion.

Most employers are looking for one of these types of hires:

  • An Engineer that can build small features with help of senior staff
  • An Engineer that can build large features as part of a team
  • An Engineer that can design and build a complete system independently
  • An Engineer that can design and direct others to build a large system
  • An Engineer that can maintain parts of an existing system independently

Often times bootcamps are so short and the skills gap folks are graduating with is so large that a recent bootcamp grad will meet none of these requirements.

Employers generally want every developer they hire to hit the ground running and fill into one of these categories. They want developers that need minimal training and mentorship because they believe it makes senior members less productive.

I think there should be another level - "Apprentice Developer"

I think there should be a level below "Junior Developer" with a title more like "Apprentice Developer". This where a recent grad would work closely with a more senior developer for 6 months to a year in order to become an effective Junior level developer.

The apprentice would not be expected to write any code by themselves without heavy guidance and mentorship.

What about onboarding time?

On very complicated projects even "Senior" developers might take a long time ramp up. But the difference here is that the senior dev is ramping up on business requirements and unique implementation of the software, not the art of programming itself.

In Summary

I'm not sure how long one is a "Junior Developer". Is it one year? Is it three years? It seems like it's getting shorter.

I think the definitions should be more about the capabilities of the engineer. Can they ship small features reliably? Can they ship large complex features? Can the ship entire applications?

Ultimately, these days the titles don't cary a lot of meaning. It's better to understand what the responsibilities of a role are and where they fit in context of the larger organization or project goals.

Want updates?

Want new posts about tech topics emailed to you? Sign up to the list below 👇

Also, if you are interested in learning technical topics through a video course specifically created for recruiters, don't forget to check out the courses I offer.

The main course "How to Speak Software Engineering Jargon for Recruiters" is specifically designed to help tech recruiters get up to speed fast on technical topics.

Written By Aaron Decker

I'm currently a co-founder and head of engineering at a venture backed startup called Bounty. I tend to think of myself as a backend engineer that can work up and down the stack in Typescript. Previously, I have worked as a Tech Lead and hired teams, and as a Senior Software Engineer at multiple fortune 500 companies building large products. I also did a brief stint teaching programming courses as an Adjunct Instructor at a local community college, which taught me a lot about breaking down complex things into understandable chunks.