That is the crux of this discussion. My experience is the title senior developer varies from firm to firm depending on size, and on which area of software or web development you're in.
A senior developer could:
- Have managerial responsibilities
- Have project management responsibilities
- Be involved in sales as the engineering representative
- Be a programmer who can troubleshoot and solve problems no one else can touch
- Be able to architect systems
- Be able to reverse-architect legacy systems
- Have extensive algorithmic experience and write programs that take decades of knowledge to do
- Have broad expertise, able to oversee teams doing anything from frontend to devops and networking, and know enough to steer them
- Have narrow focused expertise and be one of the top industry experts in their field
I'll give that a go:
* They can work a problem independently
* They can make newer developers around them better
* They can speak to the product owner and provide feedback on rough development requirements and cost
- They can design systems that last (functional, performant, don't need to be remade constantly)
- They can solve a wide range of technical problems (investigate performance, build a basic UI, add some ML)
I'm one of those. I don't know the latest JS frameworks. Or the ones that came before. But I can spot the problems in the project (e.g. performance, authentication, authorization), the security holes in the design before it's built, and coach newer developers on how to solve them. And I can make the case upwards for time/funding and make business cases for work.
In my professional career I've went from C++/3D graphics -> .NET -> Angular -> RoR -> React -> Django -> Flutter -> .NET Core. I've also used Python extensively for scripting and personal projects, Clojure on a large personal project, F# and Rust on minor ones, Node.js and PHP side gigs, etc.
Which is to say I've hopped a lot of stacks and technologies between jobs and side projects.
And without a doubt I can say that the ramp up time, even between similar stacks was non trivial. It took me a year to get "comfortable" with RoR even when I had >5 years of experience with ASP.NET MVC and a year with Django/Python.
You say you can give estimates for time and funding and yet you don't know the library landscape and what work needs to be done vs. what can be handled by the platform/libraries ?
And that's not even mentioning stuff like cloud providers - where there's so many cloud specific offerings you can glue together that vary wildly between providers.
You mentor people about best practices yet you don't have real world experience with the particular tech stack ? You haven't tested your ideas and how translatable they are at all and you're just assuming it translates - I've been bitten by this a few times.
So yeah I disagree, when I interviewed people I like to go over some code, ask some questions, get a feeling of how much actually relevant experience a person has and how much potential they have in transferring skills/learning - but there's no replacing relevant experience. And being interviewed like this gave me some insight into their expectations so I could judge if I'm a good fit or not.
Why would you even look at stuff that far outside your specialism? That's like saying because I'm a consultant orthopedic surgeon I can be a consultant psychiatrist. As your career progresses you will be more restricted in the fields you can enter without beginning a new career.
And yet even in these way-out examples you gave there will be transferrable experience. Data driven design from game development; memory efficiency approaches from embedded? (I know nothing about it). It won't make you senior because you're way outside your field, but that experience is valuable.
> You say you can give estimates for time and funding and yet you don't know the library landscape and what work needs to be done vs. what can be handled by the platform/libraries ?
How do you think a manager does it? They talk with their team. A senior developer is no different except having more technical expertise than many managers. You seem to take a very indivdualistic view of the role of senior developer.
> You mentor people about best practices yet you don't have real world experience with the particular tech stack ?
I said "JavaScript framework" you broadened that to "tech stack". I don't need to know the ins and outs of React hooks - there's a reason I have developers in my team who are programming that stuff and not me. I was writing vanilla JS, then KnockoutJS, then Angular 2 so the principles are familiar even if I'm not mid-level in my expertise with React 18.
Mentoring is a lot broader than "teaching how to program framework X". It's about developing skills, helping them figure out career progression, and advice and guidance. Tech is the least important part of mentoring - they can go get training for that. I detest the phrase "transferrable skills" but they are central to mentoring.
> Which is to say I've hopped a lot of stacks and technologies between jobs and side projects.
Yes. Why didn't you stick with something?
I disagree about Angular being transferrable to React, really they take very different approaches to frontend development and reading React code of a Angular dev that just started with React is full of non-idiomatic code (seen first hand when migrating one project from AngularJS to React and getting the existing team to start porting)
It seems to me like we disagree on the role of senior developer - in my view senior developer is still an individual contributor and not a manager - sure you support junior staff, but you're the guy they go for technical stuff, reviews, better approaches - not the other way around. What you're describing sounds more like tech lead/architect role to me.
> Yes. Why didn't you stick with something?
Options available at the time, boredom with projects I was working on, generally liking to learn new stuff. A mistake in retrospective, but I'm transitioning away from development to a position where the breadth is an advantage.
This actually does mean something, but SV companies have been handing it out like bullshit for so long that most of us don't even recognize that, and reject what it means as absurd because it's so completely unrelated to how it's used in our industry.
Junior means <= 3 years of experience.
Intermediate means <= 6 years of experience.
Senior means <= 9 years of experience.
Staff means > 9 years experience
"But my buddy Frank is a senior engineer at a company with three people and he just got out of bootcamp six months ago"
No, your buddy Frank is a junior engineer who took a false title
Do not get me wrong. Title != ranking either. There is no industry-wide agreement what senior engineer is. Frank might be a senior engineer in his company -- because because he proved in short time he can perform on the senior engineer level of that company.
Each of us has limits. For some it is Senior, for some it even could be Junior. If people are happy in their level, there is no reason why they cannot be productive for many, many years.
I disagree with this: In my 20 years of Software Engineering, I've seen plenty of super smart, knowledgeable and enthusiastic Junior and mid level engineers making wrong decisions that "in theory " look right because they just haven't seen enough production systems.
Battle scars are quite valuable, particularly when shit hits the fan and you gotta draw from your previous experience to understand what REALLY is happening in very short time.
As a specific example, in a previous startup 8 years ago, we were 3 engineers. Two of us had good field experience and the other guy had outstanding academic/algorithmic skills (he won several algorithm competitions). At some point some crap happened to production systems. When the 3 of us saw the logs, he suggested a couple of root causes that just were not really probable. The other engineer and I could "read between the log lines" and got to the real cause pretty fast.
Disagreeing with social norms doesn't strike me as humble.
I didn't say anything about whether experience was important. What I said was "these words are used to describe years of experience, and people trying to use them to describe skillset are making an error."
Most of the resume is about skillset. Why try to make this about skillset too? You've got entire lists of your specific skills, plus your jobs where and how they were applied.
To me, this seems like saying "no, college degree means I have the skills, skills are more relevant than education, I didn't actually get the degree but I have the skills, so I can wear the title"
Except that phrase doesn't mean "skilled," it means "years of experience," just like a degree doesn't mean skilled.
The reason we in hiring want to know how many years someone has under their belt is:
1) Everyone who's been in the job two years thinks they're the smartest and most motivated and that means they're just as good as everyone above them, and
2) Very little about seniority is actually about skillset. It's mostly about being able to define work, to be dependable, and to be able to clearly communicate expectations
.
> There is no industry-wide agreement what senior engineer is.
There doesn't need to be. This is nationwide, across industries, and a matter of law for government jobs. Agreement, by industry or individual, isn't relevant.
This would be like asserting that there's no industry-wide agreement on what age of employment is. There doesn't need to be; we have society for that.
You can crack any HR college textbook and look this up. These words have meanings, regardless of whether you imagine an industry wide agreement exists.
What use does a word like "senior" have if it means something different company to company? What's it even there for, at that point? In hiring someone, what do I learn from "oh well they performed at that company's senior level?" Do you think I know what every company individually defines that word to mean? Who is gaining calibration there?
we're leaving in different social circles... so it is totally possible that the norm i see differs from yours.
I worked once for the startup where idea was, "engineer" does not need prefix. Salaries, responsibilities, you name it -- were different. The title (in R&D) was not. Nobody cares.
I did not say "skill". I do not care about skills any more than I care about years of experience. The only thing I care about is ability, willingness, and readiness to contribute. The same person might match differently in different companies. E.g., intimate knowledge of C++ in embedded systems (e.g., avionics software) might be highly irrelevant in web-oriented startup, which is pushing Python. Would 10+ years engineer qualify for "staff" position? definitely no. "senior"? -- maybe. If Boing had layoff, it might be an option for somebody to restart carrier. A good person will quickly grow through the ladder, in the same company or moving on. But immediately? please.
> a matter of law for government jobs One can think of government as a single employer. In my company there is a levelling guide. We do not care about government, government does not care about us. :-)
No, it doesn't.
It just means that the word "senior" measures experience, not skills, and is frequently misused.
It's fine to prefer a super skilled junior, and smart companies do that all the time. But that doesn't somehow make them senior, and failing to understand the distinction is a significant problem for hiring.
.
> An extremely smart and motivated programmer with 3 years of experience is going to be far above a programmer with average intelligence who phones it in.
My experience in industry and my personal viewpoint is that actually lazy programmers tend to be the best. They don't over-engineer things, and they write their tests, because they know it's better to spend an hour now than five hours next month.
My experience is that smart and motivated people tend to fall on the Knuth side, and not the McIlroy side, of More Shell Less Egg, and this is not what I personally want.
https://leancrew.com/all-this/2011/12/more-shell-less-egg/
Anyway, this is all irrelevant in my opinion. We can hem and haw until the cows come home about who's going to be a good programmer, what styles we prefer, what candidates we prefer, and who knows, maybe one of us will get lucky and say something correct one day. Most people never do. :)
In the meantime, these words formally refer to years of experience, and if you want to focus on their skillset, then read their list of skills, instead. The standard resume has not just an explicit list of skills but also how they were used in previous jobs, and this doesn't come up this way at all outside of hiring. It's a concreted matter; you can look it up in HR textbooks, and in government jobs it's a matter of law.
Similarly, their education isn't about their skillset, but it's important, and it should be on the resume. (Originally that said "phone number" in the hope of being funny, but it came off as sarcastic.)
Yes, skills are very probably the most important thing you can find on a resume about a person you're going to hire, and almost the most important thing about them in general (behind honesty and workplace toxicity.) But also other things are important too, and not every single thing on the resume needs to be about skill level.
When I want to know years' experience, there are other reasons I want to know that, beyond their skillset. It'll have a lot to do with whether they know how to document, how to gather requirements, how to write plans, how to contact stakeholders, how to push back against bad decisions, how to communicate schedule slips, how to make themselves available.
Yes, skills matter a lot, but also, the stuff under years of experience do too, and there needs to be a way to communicate that.
If I had the magic staff-reader wand, and two candidates, and it said "super skilled junior" and "average senior," there are actually times where I would prefer the latter. Not a ton of them, but also not zero.
Don't co-opt everything towards skills, or you'll blind yourself towards other important topics.
You say you have relevant experience - will you show them your work so they can review it ?
I have a friend that has >7 years of experience - which was spent on obsolete stack in huge corporate contexts - you put him on a new project to bootstrap a generic app and he's basically a junior/mid with some debugging experience and knowledge of SCRUM.
And this was made obvious to him by multiple interviews/tasks he had to do - after which he basically had to spend 6 months getting up to date to be able to work on modern projects.