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!
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.
* L2: $80-110
* L3: $90-120
* L4: $100-130
You would ideally want to go in as an L2 at $100 because then the silly game of corporate promotions works in your favor. Typically its easier for lower levels to get promoted and promotions usually have some bump % tied to them. If you enter at L4 you may find progressing into L5 or L6 takes much more political savvy, luck and time than actual merit. At some point most people, statistically speaking, will top out at a title and salary either because the pyramid nature of the hierarchy means its super selective to move up or because they have plateaued with skills, etc.
1. That you know the per-level salary bands before you join the company (this is often not public information)
2. That the salary bands overlap to a significant degree
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.
2) If you had to give an objective definition of a senior developer, it might be somebody that can design and plan out complicated product features on their own and who others turn to for guidance. That doesn't mean that seniors don't sometimes need to collaborate with others, but generally they can figure out how to solve most of their own problems without having their hand held.
- 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 taskI 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.
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.
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...
It's supposes to mean years of exp and expertise but whatever
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.
At a bare minimum I think you're looking at someone who has a solid understanding of the code base and business they're working in.