It can be resumed to the aspect of solving problems (because this is what we, the engineers do).
junior devs - are given a solution to a problem to implement
mid lvl devs - are given a problem to solve
senior devs - are given a project to find (and fix) problems
> senior devs (principle, etc, names different by company) - are asked before making a project what the problems will be.
The more experienced will be the less "do that" you'll have.
Based on what they do, usually:
junior devs - work on top of what the other devs do, usually modify stuff
mid devs - develop small chunks of code (ex classes in a framework)
senior devs - develop the basecode (ex the framework)
> senior devs - develop the architecture that the senior devs develop on, solve future problems and select the next technological direction of the project, find the future scalability issues, etc.
I don't believe in magic numbers rules like "you have to know x paradigms" "x programming languages" "x years of experience".
The "x years" is the biggest caveat, most of the devs I saw have "1 year repeated x times" of experience.
These are great points. I'll add that that some of the "what you do" is highly dependent on the team size and the problem at hand. It's perfectly reasonable to be hired on as a junior to essentially build something from scratch if it's a small company or an indie project or something. Would obviously be way less common with a big project.
I know from experience: My first real software development job was "CTO" of a two person company 😋
The levels of seniority make sense only where the other positions are filled, for my first jobs I was a Junior but I was also the most experienced so I had to do the Senior+ grade things (including software architecture, database and system design).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It can be resumed to the aspect of solving problems (because this is what we, the engineers do).
The more experienced will be the less "do that" you'll have.
Based on what they do, usually:
I don't believe in magic numbers rules like "you have to know x paradigms" "x programming languages" "x years of experience".
The "x years" is the biggest caveat, most of the devs I saw have "1 year repeated x times" of experience.
I think you mean principal not principle : )
These are great points. I'll add that that some of the "what you do" is highly dependent on the team size and the problem at hand. It's perfectly reasonable to be hired on as a junior to essentially build something from scratch if it's a small company or an indie project or something. Would obviously be way less common with a big project.
I know from experience: My first real software development job was "CTO" of a two person company 😋
Yes I will add:
The levels of seniority make sense only where the other positions are filled, for my first jobs I was a Junior but I was also the most experienced so I had to do the Senior+ grade things (including software architecture, database and system design).