No, no one calls someone with 5.5 years of experience a junior engineer.
After more than a 2 decades in software development (rails/web/...), for me to consider a developer to be a senior it needs to:
* Communicate: For example: can explain tech concepts to non tech people, or inform on Monday that the sprint will be unlikely to be done in time.
* Can estimate and adapt to changes. Be boring and predictable.
* Can work/collaborate/teach with other devs.
I got tired of interviewing tech people that though that to be senior is the same as to be specialist (or worse even, that it was related with the number of years).
I've promoted juniors in months. I've also had people start, stay a few years and leave as a junior. It's all about learning and what work you take on. Also, I see this often when interviewing. 5+ years of experience looking for a junior role. Usually, it's either someone who did not learn and was not promoted, or it is someone from an company that did not let people work on important things because they were junior. So they stayed that way.
A programmer can program code good enough, but that doesn't mean they are good at solving the goals business requires and communicating it.
A developer can program and develop a small enhancement with good communication. Sometimes can also break things down so other developers or programmers can work on it to.
An engineer an orchestrate an entire new project and can identify multiple areas where developers and programmers can be involved. A good engineer will do so while maintaining great communication with the users to ensure they get what they want.
An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings.
Disagree for both cases. The building architects I know surely have to work with a given budget and in software architecture likewise.
I wonder if any newcomer to an organization, regardless of how senior they are, won't be in this same position. In order to solve business goals, they need to understand them properly. In order to understand them properly, they need context. The context comes from working in the organization for some time (months to years, depending on the size and the transparency of the organization).
This is definitely not true. I always have to balance on time/on budget/meets requirements and the skillset of the people who are using my designs.
Whenever I hear developers say stuff like this, they just sound junior/inexperienced.
https://news.ycombinator.com/user?id=m00dy
about: someone important...I had colleagues with 20+ years of industry experience who couldn't communicate efficiently, extending every short call to 1h+ meetings, require long and recurring discussions for the smallest details, or define tickets that always had to be reworked. The same people were often off by magnitudes with their estimates and reluctant to suggestions to improvements in their tooling (i.e. linter plugins for their IDE when necessary).
On the other hand, I had teammates with ~5 years of industry experience who outpaced the whole team, delivered optimal quality, were empathic, held workshops for other devs, and still had enough time/power to work on things like refactors.
Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring. If you can pass to a dev some business requirement, and know that they'll return with an optimal solution implementation, you've got yourself a true senior dev.
I was horrible at communicating succinctly in both written and oral form and bad at PowerPoints and diagrams until 2016 - at the age of 42. I definitely wasn’t comfortable talking to “the business” and customers.
I got my first dev lead job and watch how my manager - the director of IT - at a mid size non tech company was able to translate my technical designs and challenges to the higher ups. I learned a little from him through osmosis.
I changed jobs in 2018 and I started proactively working with my CTO (my manager), sales and the documentation writers to become a better communicator.
By the time a chance to interview with BigTech in the cloud consulting department (yes full time job) fell into my lap in 2020, I had no problem passing a 5 round mostly behavioral interview where I had to describe technical accomplishments, business impact, scope, etc in STAR format - over video conferencing without the use of a white board.
I was still a little rough around the edges. But three years later, I consistently get great feedback from customers about my presentations and my ability to explain concepts and challenges to technical and non technical audiences at the same time. I’m not bragging just saying that it can be learned like anything else.
On another note, being able to work independently when spoonfed business requirements is considered mid level behavior according to the guidelines at every single major tech company that I’m aware of.
But part of it was also me just watching people who were good at small talk and reading articles about how to be a good conversationalist since I am on client sites and go to lunch/dinner with them.
For instance, since I work remotely, I’m constantly taking notes when I’m on client calls and even with internal people when they mention something about their personal lives - families, vacations, hobbies - so I can ask then about it later.
Heck, I even have scheduled messages on Slack to ask them how was their vacation to $x when they are scheduled to return.
How does that work? Explanation is fairly important there, I'd have thought.
> Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring.
See, I think this may be the disconnect/product of title inflation.
In a system where you have junior engineer/engineer/senior engineer, what you're describing is probably engineer, not senior engineer. In a junior/senior system, it's, ah, a senior junior? :) A senior engineer should be a kind of force multiplier (though such is the level of title inflation that that maybe is now more staff in some places).
I wrote a blog post about it: https://www.mooreds.com/wordpress/archives/2812 which got some great HN discussion a few years ago: https://news.ycombinator.com/item?id=20485006
tl;dr: being a senior engineer at a startup is different than at a consulting company is different than at a large retail firm is different than at a FAANG.
* able to take responsibility
* able to transfer skills and to guide juniors to productivity
This is the big difference - seniors will track and resolve a roadblock or issue that they could justifiably ignore, in particular where other people in the organization are being difficult or obstructive, giving incorrect guidance, etc.
A junior will just go "We were told it cant be done/will take 5 weeks" whereas a senior will know that's bullshit and escalate it to the right people.
I'm my environment, senior developer needs a deep understanding of technology but more importantly a deep understanding of business and business processes. I'm in the ERP space so a senior Dev can talk business language - they Co develop and guide functional specifications with business analysts. In other words they understand hr or pay or financial processes of the company.
I wish I could assume all those other qualities as well, but while some here think good communication is easy to acquire early, my experience is the opposite - there are many 20 year veterans that cannot / should not be put in front of a client. They are wizards at technology but not at communication - presenting things to non experts, understanding other points of view, etc. You have to WANT to learn things other than technical proficiency, and even here, that's frequently derided / seen as uncool. "Manager" is of course a swear word insult so anybody who wants to learn communication or empathy or estimates or hard conversation is "no true techie" :-/
I call it do you have 10 years of experience? or do you have 1 year of experience 10 times?
No one says everyone with 5 years of experience is a senior, but most likely is mid.
- dev lead - non tech company responsible for one “team” of two developers and a bunch of contractors on another team
- “Senior Software Engineer” - no reports and I actively refused a promotion to be a team lead. I was already the de facto “cloud architect” over the “application modernization” efforts via no more than influence and reputation.
- mid level “cloud consultant” - full time job working remotely at BigTech.
It could last longer if your company does not have a normal title (i.e., they consider junior == !senior), but someone with 10 years of relevant experience should have earned a seniority title of some sort.
Seniority is about experience and not skill in my opinion, we see many talented developers who don't qualify as senior because they simply haven't experienced enough situations. I expect a senior to have some war stories and a breadth of notable situations that they can walk me through, to demonstrate their ability to predict common issues and pitfalls, and to show how their experience helps their troubleshooting and informs their choices.
If I had told 20 year old me this, 20 year old me would have balked. 20 year old me was an excellent programmer, but he didn't know shit about long term software development.
For me, this most often comes up when acting as a reference for someone. The hiring person will ask me stuff, and often a 'senior' label question will come up. Almost invariably the person I'm acting as a reference for is beyond 'junior' connotations, and I think have to ask what the hiring person mean by 'senior'. Getting their definition helps me answer most effectively.
"Yeah, AB is pretty close to what you class as 'senior'. He's going to work well in a larger group with defined roles and a set schedule, which it sounds like you have."
"Well.. SJ is not 'junior' any more, but does need to have someone more senior to help mentor/check in on more advanced topics. If you don't have that - if this is a 'lone wolf' role, they may struggle some".
These are just my opinions though, it differs from company to company. One place the difference between a Developer and a Senior Developer was a senior could be expected to own a feature and all the moving parts to get it deployed, eg: taking it to the board, organising all the approvals and business requirements with other teams etc. Other places senior just means "not junior" and the roles are the same, you just expect more talent from the senior.
Yep. I've been doing this for... almost 30 years now, and... interacting with 'seniors' with 2 years of experience is really weird. My recollections from the 90s having worked inside a few places was that 'senior' had a lot more weight/heft to it. It indicated, at the very least, long experience (8-10 years or more) and some ability to at least work with other tech people (non-tech was a bonus).
Can't quite figure out when this shift started, but have definitely noticed title inflation as a regular thing over the last 10-15 years.
Have you ever taken down a database by mistake? Dealt with bad backups, "on production only" issues, rounding errors in historical data, security breaches, multibyte character set conversion issues?
"Coding" is eventually only a small part. Better coding skills up front can help prevent or mitigate some of the potential issues listed above, but only to a point. You're not always even the author of all the code in use; learning how to deal with that, maybe under pressure of "prod is slow/down", has an impact on how you consider these issues going forward.
EDIT: tangential story
I was at a meetup years ago, and one of the "senior dev/architect" folks at the company hosting the meetup was talking informally about IDEs. I jumped in a bit as I'd recently started with IntelliJ (this was... 2010, I think) and was excited to share a few bits that were new to me.
As I listened more, the guy was lecturing the meetup folks that "IDEs were really for juniors and newbs". Specific language is somewhat lost to the mists of time, but the gist was "This is your code, you've written it, you should know it inside and out; fumbling with slow IDE just burns productivity, wastes time, and just shows you don't really know the codebase."
I eventually interjected that it might be reasonable for him, personally, to know all the code in a system that he'd built up from scratch over the last 7-8 years. However, for anyone new coming in to the codebase, an IDE is invaluable because it makes the entire thing far more discoverable. Jumping around between sections helps you learn and narrow down bugs/issues much faster. "Well, you should just be asking your senior if you have questions" was the main response, and IDEs were still beneath him.
I realized a bit later he was actually giving a small pitch; as host of the meetup, they had an intro period, and they were recruiting. I'd heard about this company before - growing, funded and in a space I had some experience in. Had 0 desire to work there after talking to him. But "the senior architect" always knows best in many places. :/
I'll bet it can be tracked down by looking at job-hopping. That's how it happened to me in the early 2010s: I was never told I was promoted to senior developer, one day I was just invited to a meeting for all our senior developers to get opinions on something. I hadn't noticed before, but during the meeting I realized I technically was in the older half of all the devs in the office (in terms of time at the company, not age), just due to all the hiring that had been done in the previous year or two.
Of course this is about the level the employee is capable of operating at in absolute terms but hiring is relative. In an employee's market someone might be able to land a "senior" role before they're really ready for it. In an employer's market the average candidate who gets hired as a "senior" might have 10+ YOE. We've gone from one to the other recently and everyone's expectations will need to adjust accordingly.
I think I would drive myself mad if I tried to live up to the crazy expectations of senior from most internet commenters.
And maybe that's the point of it. Senior without the title inflations is meant to be an actual high level position - not 50-100% of the company.
A lot of places have just replaced senior with staff/principal engineers instead, but senior used to be a well respected and unique title back in the days.
But suppose a senior is someone who can work mostly autonomously under general direction from their management and tech leadership, which I'd say is a reasonable basic definition of what "senior" level has historically meant in software development. We would expect to see a lot more people reaching that level and sticking around on a tech career path now because of the rapid growth in the industry and the greater awareness that people can be a high-level IC but not have much interest in formal leadership or management roles.
Moreover there is no rule that says an employer should hire mostly juniors, some mids and only a few seniors. Good seniors are almost always disproportionately cost-effective if you can manage to hire them. The trend for rapid job-hopping has left juniors as an almost worthless hire in many cases because they probably won't be around long enough to make a good contribution in return for all the early overheads they incur.
There is definitely a longer formal tech track in large organisations now. I'd say it used to be more that you reached senior and then any other responsibilities like leading a team or dealing with large-scale software architecture issues were kind of attached. So historically you'd associate those higher responsibilities with "senior" people where today those with the skills and experience to do them probably have higher job titles like lead/staff/principal instead.
So I'm not sure senior has been deflated or replaced by staff etc. It's just that senior used to be the top of three levels for many employers but now there's more recognition that your development doesn't just stop after a few years and "senior" today mostly means "first few years as a senior" in old terminology.
That's where I disagree. A senior should do a lot more than that. Seniors would mentor and train juniors. Software or not - that's how it's traditionally been.
What you describe is more like an engineer (no senior). Juniors are the 1s that can't work autonomously. When you are recognized as fully fitting the role you're just that. A senior then excels the role.
> We would expect to see a lot more people reaching that level and sticking around on a tech career path now
What does this have to do with what roles are available in an organization?
I start a company. I have 1 CTO, 1 tech lead, 2 seniors and the rest are engineers. What level someone is at should not impact what I call the titles available, but to suit the current market, instead we have 1 CTO, 1 principal engineer, 2 staff engineer, 1 tech lead, some seniors and a few engineers. Same same. No 1 actually grew additional roles.
It's all a trick to make people think they've levelled up.
I agree that was typically also something that came in at senior level.
Maybe it's a regional thing? I'm in the UK. I'd say it was fairly standard here for a junior to be someone in the first couple of years on the job who was still learning the ropes and probably couldn't do much beyond very basic grunt work without the assistance of someone more senior. Losing the "junior" label came when you got beyond the near-full-time hand-holding and started doing routine stuff independently. The "senior" label came when you could do the less routine or more difficult stuff mostly independently as well.
What does this have to do with what roles are available in an organization?
It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.
There are 2 distinctions and that's what might be confusing. 1 is your experience/level and what you're referring to. The other is the roles an organization offers.
I might have 50 years of experience but if the other roles are taken by more qualified people in THAT organization I can take a normal engineer route. Doesn't have to be senior. It doesn't make myself not qualified to even be a CTO elsewhere.
The roles are fixed. It has to do with budget, balanced, etc. Having all seniors might mean fights and everyone wanting to contribute and pull the project in different directions. A good balance is needed. A senior heavy team might not be good just because you can.
Where we perhaps disagree is your final paragraph. The roles might be fixed but there is no rule that says they have to be. Usually things like budgets and the work that needs to be done that are fixed for the team as a whole. An employer might have multiple hiring options available that fit those constraints - for example hiring a smaller team of more senior developers or a larger team with a wider range. My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.
I don't really recognise the picture you're painting of a senior-heavy team being prone to conflict. A big part of that ability to operate autonomously that I suggested characterises senior developers is learning how to communicate and collaborate effectively without needing constant intervention from above or heavy formal development processes.
What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors. The team doesn't reach consensus and get behind its choices collectively. However it also doesn't have the stronger leadership and safety rails that less experienced developers might need to be effective. I agree that situation is bad but it's not what I was advocating before.
> I understand (and agree with) the distinction you're making.
Isn't this contradictory?
That's the trap we're stuck in. I remember Amazon HR saying their Senior titles are the equivalent of Staff Engineer titles elsewhere.
You can hire a highly experienced small team and pay each of them more. They don't all have to be "senior" in title and responsibility. They're just engineers. Fixed budget divide by the number of people (roughly) has nothing to do with titles. It only does according to some system where compensation is tied to titles.
You've said you understand the distinction but then some sentences later have just walked it all back.
> What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors.
I repeat, you're after an experienced/skilled team - not senior-heavy. E.g. you may need someone highly experienced in React and Rust with 50 years experience. It doesn't make them senior. Working autonomously doesn't make you senior.
That being said, if she got hired as a junior in the last 5 years (despite tangentially having some programming experience) and never got promoted, I guess I can understand that, but really, why even keep someone on who refuses to learn new things, is difficult to work with, and consistently writes poor code
I sometimes get even funnier CVs, where a person with 2-3 years of experience (usually from the Army) is already in a tech lead / architect position.
That's true of every field, and doesn't really relate to the claim of bimodality. If ability followed a perfect normal distribution, it would still be true that some people with 2-3 years of experience are better than some other people with 10-15 years of experience.
The difference is the kind of environment you're working in (E.g. high growth tech company vs non-tech company) and the learning rate in that environment, which is where the modality comes into play.
For example?
In pretty much any field I can think of, it is definitely not rare. The norm is that some people pick things up quickly and other people don't.
It is normal for good musicians with 3 years of experience to be better than bad musicians with 10 years of experience.
It is even more normal for good secretaries with 3 years of experience to be better than bad secretaries with 10.
My mother once partnered with a local university to offer students internships clerking in her medical office. She remarked that the students, with their zero years of experience, were more effective in this generic, unskilled role than anyone she was able to hire into it. (Those people had many years of experience.)
The partnership with the university wound down and she went back to hiring no-hopers with plenty of experience. According to her, that was the best she could hope to do for the dead-end position she was offering.