How many years to senior engineer?
swizec.com
swizec.com
Maybe the talent pool in the UK has a serious case of Dunning-Krueger?
Whatever the case may be. I find hiring extremely time consuming because I need to wade through so many candidates to find a true senior.
Take one of these "people with 5 years of experience" that are great and wait until they have 10 or 15 years of experience. Would you expect them to be a better or a worse engineer then? You need to compare apples to apples, i.e., talented engineers to talented engineers - and in this case, experience often makes a big difference.
I understand that, in our field, there is the impression that older engineers don't "keep up with progress", but this stereotype is just a form of ageism. That might be the case of bad engineers, those who were never great to begin with, but a talented engineer with a lot of experience is really hard to beat. These people can make design and architectural decision for million/billion dollar projects that an engineer with 5 years of experience would never be able to make confidently.
In a nutshell, you can't take experience alone as a predictor of performance, but there is a strong correlation between experience and proficiency.
But to be clear: I also think that roles like senior engineer are handed out far too easy.
Senior engineer since when I had less than 5 YOE - I'm not claiming anything, I'm just using the title used by my employer. Nothing good will happen if I remove the "senior" from my title - in some cases it won't make any difference, in others it will actively harm me and make it more difficult to get the attention of certain recruiters and hiring managers. I'm not sure what you expect someone in my situation to do.
Filter on years of experience - if you're right that 10 YOE is a useful threshold, it will make your candidate search much easier. I think it would be a really bad approach to hiring though because there are many incompetent people with 10 YOE and many great people with less experience. At the end of the day what you want is a good candidate, not a "true senior".
No you can’t. Some environments allow you to progress faster than others, but not this fast.
Because coding is something you master once in a sufficient way.
I think this sort of differentiation between what we expect of our "engineers" is quite useful.
i'm much more sanguine about this because you can be senior in some things and non senior in others. everything is a spectrum and also everything is stochastic, just because you have more years of experience in X does not mean you will be better at X going forward because tech changes, needs change, quality of experience matters.
all this is well trodden territory so i guess i'm just saying putting a ton of weight on an arbitrary "senior" label does neither you nor the labelee any good
the better alternative is decentralized expertise certification - which already exists, in follower graphs, open source libraries, and word of mouth.
Measuring with some kind of experience ruler that's likely to be calibrated differently everywhere seems as effective as using horoscopes. And please, before anyone objects to that, I know some of you believe in horoscopes and that' ok.
If we're not measuring actual skills then it's meaningless. Like software engineer interviews above entry level.
If we do measure actual skills senior staff should have, we have to find ways to measure those "soft skills" that we all like to claim are unimportant but are actually the big differentiator for senior staff. You don't get to be a staff engineer by rote memorization or by being the only person that really understands some tech. Well, except maybe in startups.
I get why you would have this on your list but I'm not planning on staying at a job that I don't like, or with a company that's underpaying me, or insisting to be stuck on the same project for 3 years just so I can meet someone's arbitrary criteria for a senior. And I'm saying arbitrary because:
> worked in at least 2 companies (or vastly different teams)
> worked on 1 codebase for at least 3 years
so 6 months at job 1, and 3 years at job 2 (without changing codebase) makes you senior but 10 years with 4 jobs of 2.5 years each is not senior?
This why all of this is pointless gatekeeping - you're senior if you have a senior title. And if you do, it doesn't mean all that much and that's okay.
You're missing the point.
It is about exclusion of ppl who jump between projects every 1.x year and have never witnessed whole software development life cycle.
How can you evaluate your design if you never witnessed how it matured cuz you are already out by the time this phase comes?
It's not every 1.x year, the author is excluding everyone who doesn't spend at least 3 years on a project.
It was just author's number.
It may vary by industry, specialization, etc. But the goal is the same
to give a familiar shorthand to this, I have been describing the "algorithm of career growth" by "Big L notation"
https://www.swyx.io/big-l-notation
as a way to convert from years of experience to actual skills/capabilities. people with a very high Big L learn much quicker than those with sublinear Big L. Considering that we only get one life/career it surprises me that more people do not actively design their Big L trajectory.
Senior to me means:
- Can dig yourself out of any hole. If you need help, you already have contacts who can point your way. If you need a new language/OS, you are able to understand some things immediately, but you will also know some specifics within a few weeks, since you've seen something similar. You know how to use the internet to find out about anything you come across. Your need to ask new SO questions is absolutely minimal, you can piece things together from other people's questions. You have experience outside of your area: if you're a backend dev, you can still whip up a basic web page, if you're a web dev you still know a few things about memory paging. In either case enough to know where to look for details.
- Everything that's industry standard you've either played with or heard of. You've heard of the variants of similar things (postgres, MySQL, Oracle).
- You know what the likely architectures for problems are. You know where the landmines are. You have a good idea about what kinds of requirements will blow up the budget. You know which parts are critical and which are peripheral.
- You can express why one choice or another is preferable. You understand the tradeoffs in the design. You can translate between business and software land. This last point btw is also the difference between a good lawyer and a not so good one.
Given this amorphous mass of vague seniority requirements, my guess is it takes most people 10 years of full time work. You need some time to move around projects to get some variety, and you need time to mature both technically and emotionally. You need time to meet people and get to know them on a technical level too, it's no good just to know other fresh graduates, and realistically many of your matured dev contacts will be people you met early on.
I would also say that it's possible to go 10 years without getting all this variety, which is probably a commonly pointed-out thing. But also IMO once you reach this point the curve flattens: your next 10 years are unlikely to expose to something vastly new, and so a 10-year senior and a 20-year senior are not hugely different from each other, though both are vastly different from a 5-year dev.
I mean, we are talking about a Title. Any company can give someone the title they want. I know a case of a guy who was Software Engineer at his second job with only 2yr of experience. And trust me, he wasn't a software engineer.
Can we trust titles?
At least that's when you can begin getting that title.