> whereas everyone else would call that person [with 5 years experience] a junior engineer
I’ve met people with 3 years experience who I’d consider more senior than myself (8 years). Some folks just learn really fast and/or don’t do much else other than work.
Not sure time is relevant to your skills or title after about 2-3 years.
>Some folks just learn really fast and/or don’t do much else other than work.
Maybe it's just me, but I don't consider junior/senior to be defined by how "good" you are at programming. Obviously the hope is that senior > junior, but there are other, softer, skills involved with being a senior.
(I'm not the parent commenter), but I believe a defining quality of a senior developer is someone who I can give any problem/project to in the business domain and they return with a solution in the technical domain.
You've already invested a huge amount of time in learning something which became obsolete (like jQuery), then you got over it instead of giving up in frustration, and spent a huge amount of time learning something else (like Angular or React), and you've finally come to grips with the fact that it too will eventually become obsolete, and you'll be fine moving on to the next thing (like Svelte).
If you only know one system and think you're going to be able use it forever, then you're still a junior developer. If you're afraid to move on and learn something new, then you shouldn't be a developer at all.
Someone who's reached their last year of high school. Seriously though, senior just means you're older and have more years of experience. Make sure you help your kouhai when they're in trouble.
Experience is absolutely relevant. You are vastly more likely to be competent at 10 years than 5 or 3 or 1. Sure, I have worked with incompetent people with more experience and I've been the "rock star" with 2 outperforming devs with 15, but there's still a strong correlation between experience and ability.
> Not sure time is relevant to your skills or title after about 2-3 years.
I cannot disagree with this more. In my own experience, I've never met anyone with less than 5 years of experience that I'd call "good". And I've worked at several places in SV, FAANG included.
The idea that "experience" is an outdated concept would only make sense coming from an industry that really doesn't even really have "senior" people.
Having worked in multiple fields throughout my life, I deeply miss the presence of truly experienced coworkers.
For example one of the lessons of experience is that skill in the immediate task at hand is only a part of the overall engineering skillset. Experienced professionals (in any field) can often solve problems better with a tool they are unfamiliar with than less experienced professionals can in their area of expertise.
One trait of experienced devs I've seen, that I've not seen in even the sharpest but less experienced ones, is the ability to see problems that will arise down the road from miles away.
Likewise I also rarely see less experienced devs, no matter how smart and talented, see solutions outside of the main path massively reduce the complexity of the original problem. I fondly recall working in research orgs when I was much more junior, and asking a 30+ year industry vet how to solve a tricky problem only for them to, time and time again, that the best solution was to avoid the problem.
> ...industry vet how to solve a tricky problem only for them to, time and time again, that the best solution was to avoid the problem...
This is a world-wide, ancient, phrase: If it ain't broke don't fix it.
Which derives from the universes oldest rule: Nothing is more permanent than a temporary fix.
Senior devs have internalized these two constants of the universe. I suggest you do as well, before the third rule of the universe takes hold of your life.
Third immutable rule of the universe: He who noticed it, broke it.
> One trait of experienced devs I've seen, that I've not seen in even the sharpest but less experienced ones, is the ability to see problems that will arise down the road from miles away.
This is called second (or third) order thinking btw.
If you have a hard time contributing to starting on projects or resolving problems, AND you have a hard time contributing to finishing projects or resolving problems, you’re a junior X (where x is programmer, engineer, sysadmin, etc).
If you can contribute to starting on a project/problem but have a hard time finishing it, OR you have a hard time starting on a project/problem but can contribute to finishing it, you’re an X.
If you can contribute to starting on a project/problem, AND you can contribute to finishing a project/problem, you’re a Senior X.
Not sure the current term of art to being able to start and finish projects / solve problems and your work regularly being good and reliable, maybe Architect or something like that.
I like this heuristic! It captures several important aspects of "seniority" in a clever way.
A lot of the other comments are defining seniority in terms of years of experience or breadth of skills developed. Those are both important, but for me they don't capture how "well-rounded" you are. When I was a manager in consulting we used to distinguish between resources who had "5 years of experience" and resources who had "1 year of experience 5 times". Your years of experience need to be extending your capabilities, not just repetition of skills you have already mastered.
I think simple rules of thumb, like "5 years is a junior" or "5 years is a senior" aren't very helpful. When I'm hiring I may suggest a certain amount of experience as a requirement to indicate to candidates that I see the role as suitable for someone "entry-level" or someone further along in their career. But I'm not going to reject a candidate with good experience simply because they don't have the number of years experience I suggested. I'm going to look at what they've done.
One more thought on this topic. For me, years of experience can also be shorthand for variety of experience. Someone with 3 or even 5 years of experience is unlikely to have worked on a lot of big projects in different organizations. Someone with 15+ years of experience is more likely to have worked on a variety of big projects in different organizations. Some commenters here are probably going to tell me "5 years of experience at a start-up" is as good or better than 15 years of experience in a big corporate IT shop. Maybe. Depends on the role I'm trying to fill.
If I were hiring for my farm business, I would consider years of experience to have some relevance. Every year brings a new environment (e.g. drought, rainy, etc.) and, with the work being largely seasonal, it takes a whole year for a chance to try again. As each year brings new challenges, having another year of experience does strongly indicate that you faced a new challenge each time.
If I were hiring for my tech business, I agree that it doesn't mean a whole lot. One can experience a multitude of different environments before lunchtime. One can also do the exact same thing over and over. There is no seasonality to hold you back or push you forward.
Ultimately, what one is interested to know in questioning years of experience is how many scenarios someone has run through so that when something similar happens again you can believe, with reasonable confidence, that they will know how to react. This is quite measurable, but it can be hard for someone in tech to keep track of as there isn't a good frame of reference like in farming where you can simply remember each year.
> All this tells me is you've never worked in agricw
Honestly, I don't even know what agricw is, so that is no doubt true. I've been working on farms for 30-some-odd years, though, and my farming operation has been going for 17 years now, so I speak from that background. We plant once a year, we harvest once a year, etc. so the lessons to learn only come around once a year. Thus years of experience starts to become a decent proxy for what you are really trying to measure. Indeed, that doesn't work in every industry.
I've never really considered the ability to write the code without handholding to be the line between junior/senior. If anything that's more the line of being a competent developer with a particular toolset.
I may be a competent framer that can stud out the plans for a house, but I may not totally understand why the walls are positioned that way or how the roofline will work with the landscape to avoid water issues later. They're just different skill sets, I'd actually also expect the architect who can design the house wouldn't be particularly useful with a framing nailer.
Ive never actually liked drawing solid lines between skill levels because it is so contextual, but here's the closest I can get.
Any developer should be able to write code when it's already known what it needs to do. The next level for me is being able to write code with an eye towards testability, maintenance, and flexibility based on where you expect requirements to change later. I'd expect a senior to be able to go beyond that, starting from a set of product requirements and designing the code to work for those needs. Beyond that it starts to get really gray, and you likely lose more of the earlier coding skills, but that's where I'd be looking for someone who can help define what the product requirements even are, considering technical risks and limitations of how they might even build and host the product.
I see it like the most abstract up the ladder you get, the more senior you are.
Anyone can fix a button's css.
Not anyone can refactor big parts of a codebase into something better, or help them create from scratch in a cohesive, modular, future-proof way.
Every time I get into a new job I get a various degrees of this.
The more business-context you have, the better you can solve business requirements with tech, the better tech toolset you have available, the better choice you can make on what solution to use or not to use to such problems.
True seniority means understanding how all the system works, regardless of getting into the grunt work of each of the steps, but being able to do so and understand it at the lower level too if/when needed.
One caveat I have is that companies are generally terrible at recognizing senior+ level independent contributors (ICs). Many companies don't even have a career path defined for this.
I have worked with some of those individuals and they really are worth every bit as much as, if not more than, a systems-level thinker that enjoys mapping business needs to technical solutions.
Most large tech companies I've seen promote standout ICs to either architect or manager, assuming that the skillset and interest largely transfers. I've seen this blow up many times, it's painful to watch and I really hate it for everyone involved.
Junior is mostly related on the scale of responsibilities. Juniors take on tasks, middles on features, seniors are responsible for products, staff for a series of related products, and distinguished engineers are responsible for huge leaps in key core parts of the business.
I don't think it's about learning very fast. You learn the technology as you use it.
It's about having the brain to reason around problems efficiently.
I worked with someone who become senior & team lead after 2 years (and a really good one at that), after having done business PowerPoints for their entire working life.
I link IQs test (in informal channels) and all the juniors who picked up development really quickly and become very effective, all have high IQ.
If it were allowed, I would definitely use IQ tests in an interview setting.
I think leetcoding started as a proxy for IQ tests (which could totally be, if people couldn't prepare on the subject) but nowadays it's just testing people's ability to memorise different cases and being comfortable enough with coding to be able to implement (and mix and match) them.
There is the saying that to get 5 years of experience in 1 year you should work in a startup.
This isn't only about title inflation. It is in some ways true in the real sense also. Because in a small team you get exposed to everything and if things don't work, it's very obvious why and there are no excuses to hide behind. Whereas in an enterprise you could sleep behind the wheel, roam around in pointless meetings, wait for the other department blocking you, ride on your teammates merits, close 1 story per month and nobody would question.
This isn't to say there aren't great minds in big organizations, I've been in both contexts and learned tons and met absolutely fantastic colleagues and experiences in both.
I think you hit the nail on the head there. I’ve only worked in startups and consistently I’ve worked with “senior”-titled engineers who were absolutely brilliant. Typically with less than a decade of experience.
But yeah there’s definitely no cruising at the wheel when you’re in a small, fast-moving organization. In my experience it’s helped me level up very quickly.
I’ve met people with 3 years experience who I’d consider more senior than myself (8 years). Some folks just learn really fast and/or don’t do much else other than work.
Not sure time is relevant to your skills or title after about 2-3 years.