I’m a developer with 15-years of experience in the .Net stack as well as an interest in Angular.I’m known for taking legacy projects and updating them so they can be maintainable and have new features
After 2 decades in tech I have stopped putting faith in titles/roles and tried to spend more time figuring out the character/motivation/strengths/weaknesses of the person behind them. If this comes off as a non-answer, it is not intentional.
Here is why.
Skills, roles, titles - those are manipulated on a daily basis to get past the HR screens and the search engines. But without context, those are meaningless. If you are a 3-person startup then the "Senior Developer" is the person doing the most work on the product short of setting the directions/strategy. And if you are in a giant company with tiered roles, then you could work for a decade and still be a "Software Engineer Level X" when you retire. Is one better than the other?
It's all about context.
To me, it matters WHO is asking and WHY.
When a recruiter says "Senior Developer" they are looking for years of experience and possibly your holding that exact title in another company.
When a manager says "Senior Developer" they are looking at the relative strengths of people already on the team, and looking for someone who has the ability to work independently, deliver results and collaborate-on/lead initiatives that require harnessing diverse skills/personalities towards a common goal. By contrast a junior developer is one who is learning the ropes IN THAT CONTEXT and is therefore not likely to have the experience/confidence to manage things independently.
We are all junior developers when we tackle new domains or technology platforms.
We are all senior developers if we are asked about projects we have personally worked on, designed, architected or shipped.
I personally think we need to get rid of these gradations - I know from industry that titles tell you nothing about capabilities. Instead they reflect salaries, access rights and decision-making powers - which effectively group people into buckets without recognizing their individuality.
Instead I think a better way is to say "I am a Software Developer with X years experience working on Y in the Z industry/domain" -- in a startup context, that could qualify me to be a VP Engg while the same thing could qualify me to be just one of many Staff Engineers in a bigger company.
But that minor rant aside, here is what I see as the core qualifies of a "seasoned" developer.
Constantly learning. They recognize that tech changes fast, and keep one eye on the horizon.
Problem solving. They recognize that they DON'T know everything but they have the self-confidence to ask others for advice/help and to get their hands dirty trying out different options till they have one that works, even if it is imperfect.
Collaborative. They realize that they are neither at the very top of the food chain, nor at the very bottom. And that to survive/thrive, they need to work with both their junior team members and their senior team managers. That requires a certain expertise in personal interactions, empathy, compromise and willingness to listen - that is really rare.
Autonomous. They value independence and can reliably deliver results without constant oversight and hand-holding. More importantly, they are proactive in reporting both successes and failures. The hardest thing in tech is to be willing to take responsibility for failures - or give people bad news. The true test of seniority (for me) is the willingness to take accountability with the clarity of realizing that it is another lesson learnt that will help improve the product/project in it's next iteration.
Pragmatic. They understand that some battles must be lost in order to win the war. They don't get dazzled by every shiny new bauble of tech that comes their way - and instead focus on making "best decisions for current contexts in limited time". In that sense, seniority benefits from multiple years of experience - junior engineers are those facing a situation/context for the first time (which can result in analysis paralysis), while senior engineers effectively shrug, say "it happens", and get to figuring out how to fix it and move forward.
Note that none of these are tech/platform specific. Most are behavioral - and IMO those are some of the most intangible (yet critical) aspects of hiring that today's interview processes fail to asses correctly.
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.
This seems fortuitous as I'm trying to nail down the skills and qualities of Sr. Developer today and would love your input.
dev.to/programazing/which-qualitie...
After 2 decades in tech I have stopped putting faith in titles/roles and tried to spend more time figuring out the character/motivation/strengths/weaknesses of the person behind them. If this comes off as a non-answer, it is not intentional.
Here is why.
Skills, roles, titles - those are manipulated on a daily basis to get past the HR screens and the search engines. But without context, those are meaningless. If you are a 3-person startup then the "Senior Developer" is the person doing the most work on the product short of setting the directions/strategy. And if you are in a giant company with tiered roles, then you could work for a decade and still be a "Software Engineer Level X" when you retire. Is one better than the other?
It's all about context.
To me, it matters WHO is asking and WHY.
We are all junior developers when we tackle new domains or technology platforms.
We are all senior developers if we are asked about projects we have personally worked on, designed, architected or shipped.
I personally think we need to get rid of these gradations - I know from industry that titles tell you nothing about capabilities. Instead they reflect salaries, access rights and decision-making powers - which effectively group people into buckets without recognizing their individuality.
Instead I think a better way is to say "I am a Software Developer with X years experience working on Y in the Z industry/domain" -- in a startup context, that could qualify me to be a VP Engg while the same thing could qualify me to be just one of many Staff Engineers in a bigger company.
But that minor rant aside, here is what I see as the core qualifies of a "seasoned" developer.
Constantly learning. They recognize that tech changes fast, and keep one eye on the horizon.
Problem solving. They recognize that they DON'T know everything but they have the self-confidence to ask others for advice/help and to get their hands dirty trying out different options till they have one that works, even if it is imperfect.
Collaborative. They realize that they are neither at the very top of the food chain, nor at the very bottom. And that to survive/thrive, they need to work with both their junior team members and their senior team managers. That requires a certain expertise in personal interactions, empathy, compromise and willingness to listen - that is really rare.
Autonomous. They value independence and can reliably deliver results without constant oversight and hand-holding. More importantly, they are proactive in reporting both successes and failures. The hardest thing in tech is to be willing to take responsibility for failures - or give people bad news. The true test of seniority (for me) is the willingness to take accountability with the clarity of realizing that it is another lesson learnt that will help improve the product/project in it's next iteration.
Pragmatic. They understand that some battles must be lost in order to win the war. They don't get dazzled by every shiny new bauble of tech that comes their way - and instead focus on making "best decisions for current contexts in limited time". In that sense, seniority benefits from multiple years of experience - junior engineers are those facing a situation/context for the first time (which can result in analysis paralysis), while senior engineers effectively shrug, say "it happens", and get to figuring out how to fix it and move forward.
Note that none of these are tech/platform specific. Most are behavioral - and IMO those are some of the most intangible (yet critical) aspects of hiring that today's interview processes fail to asses correctly.