(But I've only worked in companies with less than 1k employees in the nordics.)
I have always prefered seeing senior devs as capable of architecting and implementing solutions (better yet delegating parts to juniors) such that they can launch a product themselves, where a mid level dev can launch individual features but would struggle with the complexity of choosing both an auth model and a persistence layer for it (mixing well with other persistence uses) and then what the front end should look like overall, and whether to use websockets or... and a junior can fix bugs, or work on tickets/scaffolded tasks in a productive manner.
If, for instance, you have 10 years of professional experience in a specific tech stack, let's say front-end development, you have mastered your craft, and you deliver faster than your deadlines, my personal opinion this should sound like a senior developer's level of expertise.
I could be wrong though, but I'm talking from experience that I have discussed such topic with acquaintances of mine.
A Sr Dev should have a different job description, different expectations and be held to different standards.
Now who get's chosen/hired for those roles is a different story...
You could have been for 18years in a company where you were the senior just because you were the only one who knew how the old monolite work. You could have been for 18years in a company without knowing more than what you were just doing. This just to say that the seniority it's not something you obtain with your years but with the experiences and situations you find yourself in and especially what do you learn from them.
Basically you forgo any income increases that you get when you change companies for the remote possibility they will make you senior someday. You also get some money.
The same title can mean totally different things at different companies.
You typically get "leveled" by a company based on your resume, years of experience, and interview performance. Sometimes companies intentionally under level you to try and pay you less than your fair market rate.
1. You negotiate a salary when interviewing. 2. If they like you at that salary they make you an offer 3. HR assigns you whatever title corresponds to the salary band that contains the salary you happened to manage to negotiate, as per HR's list of salary bands.
In other words, in theory, the system is supposed to look like they go find an engineer, figure out if they're senior based on interviewing them and other signals etc, and if they're senior they get the senior rate.
The reality is the opposite-- they just figure out whether they want you bad enough to pay the rate you want, and then, if so retroactively justify it as corespondening to whatever HR says they have to call you back I justify that salary.
So for example, this makes it easy to end up with a senior who is more 'junior' than a non senior, if 'senior' was hired when the job market was very hot, while the 'junior' who is actually more experienced was hired during a slow market.
Title indicates salary, not the other way around!
- thinks about the bigger picture, scalability, future maintenance, technical debt, documentation, testing, security etc.
- can see possible edge cases and how to handle them properly
- can do research alone and reason why X and not Y, can justify why X is better even though management really likes the Y buzzword
- unblocks non-senior developers in case of problems
- can communicate with product, marketing, sales, etc.
- doesn't complain in case of issues or messy code, but fixes them
- builds tools that help the whole company, not only the current task
If you have 18 years of professional experience in anything, you are senior. It's not that complicated and at that point it doesn't matter what the company is.
Not that it automatically makes you a brilliant developer. But at that level of experience you can't consider someone as junior or mid. It's senior or above.