It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know:
* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.
* Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals.
* Senior developer - Will produce immediate business value if completely ignored.
The domain and language don't matter for these, really. A Senior Go developer is going to produce immediate business value if you suddenly throw him/her into a Lisp team, too. Just slower.
When someone is considering hiring you, this is more or less what they're thinking about. It's not "do you know Scala," it's "are you going to make us more money than you cost." It's just hard to prove, for either side, so we talk about past experience instead.
>* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.
This is what people here like to believe. But I don't think it is really true. A kid straight out of college can generate immediate business value if he/she can set up an online shopping cart in Php to give a business an online presence. I am pretty sure that the same kid can code up any business requirement of most of the local organisations that does not need to scale much or work with great reliability.
Also, it is not true that a junior dev requires supervision. Anyone with sufficient motivation and an internet connection can figure stuff out by themselves. I mean, they can get things done, even if in a fantastically stupid fashion.
I agree with you. My observation is that most graduates out of college are able to formulate strategies to high level problems, rapidly create working solutions and generally be productive.
What sets us apart from the senior developers as pointed out by the CTO of my company seems to be experience in writing good, scalable code. More often than not this means adhering to best practices, linting and testing extensively and many other things that in general come with experience.
The previous post made it pretty clear that there are no timelines attached to their perception of developers - a person that brings business value to your company without supervision should not be a junior developer, regardless of whether they have decades of industry experience or are fresh out of college.
There's so much truth in this. I think it is very hard to hire actually senior developers which fit your definition, because most people who work a couple of years in the industry tend to over-emphasize their seniority.
If they did not work with exactly the tools and programming languages / libraries of the job that is described in the job offer at hand, their performance ends up more in the junior part of the scale and it will cost you dearly. I really had to learn that the hard way with several hires.
> If they did not work with exactly the tools and programming languages / libraries of the job that is described in the job offer at hand, their performance ends up more in the junior part of the scale and it will cost you dearly.
This seems to be the exact opposite of what the OP said, is it not?
Clarifying edit: It seems like you're saying that you need to have worked with a certain tech-stack for 10 years to be considered a senior developer, whereas the OP seems to be advocating that a "senior developer" will be able to handle any tech stack you throw at them in a reasonable amount of time. Their knowledge of the tech stack may impact their speed at first, but not the quality of the result.
I wanted to get the point accross that even when all checkboxes are checked in terms of programming language etc they might end up with junior level productivity (after training+grace period) because for example the project scope is different.
I have to disagree with this; a senior developer will produce more value if not completely ignored; if involved with the company, they can then not only help steer the technological direction of the company, but also move tech towards the company's future goals, not the company's current state.
If left undirected, they will still move tech and be productive, but not necessarily in the direction the company wants to go.
It is odd seeing this definition getting a lot of love here, while job ads for "Junior Developers" ask for a college degree, proficiency and 2+ years experience in Python, JS, HTML, and CSS, and a portfolio of 5 websites plus 1000+ stars OSS projects in Github.
Mostly, "Junior Developer" means "we want a developer but don't want to pay market rates".
Some of those position descriptions infuriate me. Having recently gone through a job hunt, I'm not yet ready to joke about them while sober.
I mostly agree with this definition, though I don't know who would hire someone that can't produce any business value. Hell, why bother with a CS degree if your employer is going to teach you how to do everything?
IMO, there's no excuse to have a blank resume when you graduate. Someone goes through a 4-year CS program and has no side projects? No part-time jobs, no research, no internships, no contracts, no silly hacks or anything to show for the past 4 years other than a diploma? If there's a business that profits from re-re-rewriting bubble sort I'd love to hear about them.
There are probably better ways of answering the question, but I think all those position descriptions are asking is "can you actually do things that ?"
I agree with the reasoning behind this description, but would like to add a couple points:
* Junior developer - Will produce some value with guidance, probably not much if left alone. Code will be terrible if left alone.
* Intermediate developer - Will produce value if left alone, but will write code in a way to just "make it work"
* Senior developer - Will produce value if left alone, but will write code considering the long term implications of whats been done. Is it maintanable? Is it easy to read? Is it easy to extend?
* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.
* Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals.
* Senior developer - Will produce immediate business value if completely ignored.
The domain and language don't matter for these, really. A Senior Go developer is going to produce immediate business value if you suddenly throw him/her into a Lisp team, too. Just slower.
When someone is considering hiring you, this is more or less what they're thinking about. It's not "do you know Scala," it's "are you going to make us more money than you cost." It's just hard to prove, for either side, so we talk about past experience instead.