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.

* Senior developer - Will produce immediate business value _only_ if completely ignored.

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 was a joke! The joke being that senior developers get interrupted a lot by business people and junior devs.

Many managers produce negative value!

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?

I think your definition is perfect! But in some cases senior is considered the guy who have 5+ years of experience in certain field/language.

Junior <-- +--> Senior

Requires Supervision <-- +-> Provides Supervision

Creates Systems that are Resistant to Change <-- +-> Resolves Technical Debt

Looks for "easy wins" <-- +-> Seeks to understand tradeoffs

Capitulates easily to PMs/etc. (usually to the detriment of the business) <-- +-> Demands cogent plans from business concerns

Is always right <-- +-> Fosters discussion and examination of practices (especially their own) by the whole team

Easily dazzled by new things (libraries, etc.) <-- +-> Carefully weighs benefits and drawbacks of potential tools and practices

Easily frightened by new things (libraries, etc.) <-- +-> Carefully weighs benefits and drawbacks of potential tools and practices

This is beautiful. I'm about to have a job interview where they "test" for seniority to determine pay. These are all great points for arguing why I deserve the high end even if I didn't 100% ace whatever obscure questions they have on their technical test.

I don't see looking for quick and easy wins is not a negative, nor is in opposition to understanding trade-offs.

Notice I didn't say "Negative -> Positive". It says "Junior -> Senior". Thinking about it further, I don't think it's possible to properly get to the second state (tradeoff-understanding) without going through the first (win-seeking) at some point in your career... in fact, when I'm hiring Junior devs I select for win-seeking behavior. "Tradeoff-understanding" is more of a philosophical disposition that one (IMHO the best engineers) arrives at later. "Win-seeking" is kind of related to the "I'm always right" point: A junior will say "Of course this is the best possible thing to do and there are no drawbacks" where a senior will say "Wait a sec - this might be worth doing, but let's understand what we're changing or giving up".

So, in a sense yeah - the Senior is still "looking for a win", so-to-speak but in a deeper zen-state where they realize "There are no wins: only tradeoffs".

I think the "looks for wins" attribute is just a desireable trait period (like "tries to write good code"), but the ability to weigh trade offs comes with experience and changes how one looks for wins.

In the end, you're making a smart vs. wise distinction, and the two are neither independent nor opposed.

Perhaps fixes the problem in front of them vs. thinks about the problem in context (with the context getting bigger and hairier with more experience).

I think the point is that the "easy" way is not always the right way. For example, it's easy to memoize results returned from a database for 5 minutes in response to a request for performance improvements. It's right to understand the business requirements (including performance), deployment strategy, cost of being wrong, cost of being right, and so forth.

I think an important note is that for all of those "Senior" traits, the extreme of each can be negative as well. It is always important for a developer to find a balance between engineering excellence and providing business value.

I would define a junior developer as anyone who is not going to be very effective without some supervision. In other words, they have things to learn and need guidance and oversight before they will be able to do much correctly on their own. This could focused on tools, techniques, processes, it doesn't really matter. So I don't think the definition is different for web or systems development, although the tools and depth of experience might be.

This.

Without supervision:

* can they be trusted to take a story and turn it into a list of one or more problems which are solvable and sensible to solve?

* given a list of problems, can they be trusted to select appropriate tools for solving each problem in a sane manner?

* given a problem and an approach, can they be trusted to fill in an implementation?

If you can't answer any of these questions with a firm "yes", they're definitely a junior.

"Do you have ten years of experience, or do you have one year of experience ten times?"

A junior programmer is someone who has never learned from a serious mistake they've made while programming professionally. A junior programmer is someone who thinks they should be senior thanks to the Dunning-Kruger Effect ("Hey, I was an honors student at this great college!"). A junior programmer is someone who can't usefully mentor anyone else. A junior programmer is someone who is not aware of the downstream impacts of their decisions, and is not aware that they're not aware of it.

Nothing fixes this type of junior engineer faster than giving them some real responsibility. Let them fail then learn from it. Don't hold them back because that just builds up resentment.

Sadly, it's at odds with the psychology of corporations. At big companies, it's more important to not be wrong than to be right. This is not conducive to the sort of mistake-based learning that really advances people. "Move slow and don't break anything!" is what the corporation wants, whether or not they phrase it that way.

So junior engineers aren't given responsibility, because they might break something.

I was lucky. The first time I was given real responsibility, I broke something badly (which turned out to be an actual OS bug, but that's another story). It was a learning experience - in large part, because I had to learn why things broke in production, but not in development. That lesson sticks with me to this day, 20+ years later.

"At big companies, it's more important to not be wrong than to be right. This is not conducive to the sort of mistake-based learning that really advances people. "Move slow and don't break anything!" is what the corporation wants, whether or not they phrase it that way."

This is a perfect summary of working at corporations

That post makes just as much sense of you substitute "junior programmer" with "consultant".

There's an easy way to tell if someone is junior or not.

Are you an implementer, a solver or a finder?

An implementer is someone who gets given a task and does it. That's a definition of a junior.

Middle of the range is a problem solver. You give someone a high level problem and they solve it.

A senior is a problem finder. They tell you problems before you even know they're a problem.

This guy puts it much better than me: https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...

Junior developer is someone who was unable to negotiate a stronger position for any reason, such as experience, recent unemployment, expertise in an outside specialty, company is super tightwad about 'status' and/or pay levels, naive about negotiation, etc. Conversely, sometimes you'll also see someone at a 'senior' level because the title meant more to them than pay or other benefits. Sometimes a title distinction is engineered by HR and the hiring team at a company to function that way.

It is often thought of as a prediction about what level of contribution is expected, but that's basically a farce. In every organization I've seen that makes distinctions between junior and senior developers, the only thing different between them is that senior developers are paid more. They don't do more, manage more, design with more foresight, or anything like that.

The exception is that developers who are brand new to a job function as junior engineers until they get calibrated and learn some parts of the codebase in which they can be effective. But this is just as true for a brand new senior dev with 10 years experience in your company's primary domain application as it is for a kid straight out of a bachelor's program whose only prior work experience has been theoretical REUs or something.

Basically, it's just a status tool.

You're getting down voted for expressing the reality as opposed to the the platonic ideal. Ideally junior/senior implies something about ability to work independently, but there are plenty of crappy places where job titles bear no relation to actual abilities. Acknowledging that the meritocracy doesn't work perfectly seems to piss people off around here.

This is absolutely not true.

I would expect a senior engineer to come into a new job and be able to propose the design a new service very quickly - its API, architecture, datastores (including sharding, replication, active-active multi-master designs, ...), DR strategy, how it fits into the ecosystem, how to scale it to thousands of QPS, etc.

I would too, but I have worked with plenty of people with the word senior in their title who wouldn't be able to do a any of that. I've also met "juniors" who do carry the world and build great systems.

The problem is that titles get inflated and can't be relied on as much as we would hope.

You might expect it, but I've encountered plenty of 23-year-old Senior Network/Software/whatever Engineers with just 1 year of experience. Basically as soon as they'd implemented a single feature, they would consider themselves senior.

Personally I say a senior engineer is one who solves problems by the most appropriate means. Maybe he fixes a "bug", maybe he/she knows enough about the problem domain, the use cases, the dependencies, the history and changes the documentation instead. Maybe he/she tells a junior engineer "figure out how to scale that" and uses experience to know what part of the system really needs to scale. And so on and so on. A senior engineer spends little time coding and lots of time mentoring.

This is highly subjective and very much depends on many variables, including what you mean by "systems programming" (more specifically: what level of the stack is your boundary for "system" versus "application").

There is a traditional boundary. System programming is programming at a lower level, code meant for consumption by other software, and never directly used by an end user, while application programming is meant for consumption directly by an end user. Think "game engine's network stack" versus "text editor (that isn't Emacs)".

It's possible to work as a very junior system programmer with no prior programming experience. Everyone has to start somewhere. I've put such people to work doing everything from debugging problems with some data structure implementation to debugging thorny concurrency issues. Generally I take the view that a person is no longer junior when he has had sufficient experience that he can do more than bug fixing in more than one sub-domain of system programming. That wouldn't mean he or she is necessarily senior at that point.

To me, a junior is someone who doesn't know what or how much he doesn't know. From either a technical or a practical/logistical perspective. A junior might also be someone who doesn't know how to find answers when she does recognize something she still needs to know.

A junior will either get paralyzed by being unsure where to start, or will confidently plow through a problem creating an enormous mess of unstructured code until he gets stuck either on a hard part or because his creation is collapsing under its own weight.

A mid-level engineer is aware of how much he doesn't know and also knows and uses techniques to remedy that situation. A mid-level engineer can't yet do everything on his own, but he knows that. The best mid-level engineer knows when to go to Stack Overflow for details on how to use a library, and when to ask a senior teammate for design or architecture advice.

A senior can be trusted to work almost entirely unsupervised. She still doesn't know everything, but she's had enough experience in how not to do things to be able to write maintainable and extensible code on her own. She may still run her choices by a colleague for a sanity check, and she still needs to google anything from a method signature to workarounds for a library bug to tutorials for a new framework. But she's capable of producing excellent output even in professional isolation.

And job titles mean nothing. Apparently in the iOS world, if you're not entry-level (as in fresh out of a 6-week boot camp) you're a "senior". Which is ridiculous. Not to mention making hiring actual experienced people impossible.

I'd argue experience as a programmer in other languages (say Ruby) but little to none experience in the language of the offer isn't a junior. Even if you start out in a "new" field with a different stack, the experience in other languages is transferable knowledge.

As you can see from the responses, job titles and their "levels" (junior,senior,associate,principal,etc) mean effectively NOTHING or at best vary so widely across different organizations that it really isn't feasible to take those words seriously when evaluating a candidate.

Instead of spending one second fretting about the exact useless definition of "junior", take a look at the candidate, their background, aptitudes and aspirations, their personality, your team, what the job actually requires, what you're willing to pay, and also what responsibility your org is willing to take on to train next-generation professionals. If you do that, it won't matter what "junior or senior or level X" means. The goal is to fit the right person to the right job.

IMHO, Junior developer or junior whatever means that the person has little to none experience in the field. That doesn't mean that this person has no knowledge.

Personnally, I see a Junior whatever as someone who has some theoric knowledge about the whatever but did not have the time to apply it yet.

What about those who have little theory but some application? e.g. I did marketing in college but developed and published 3 iOS apps.

As a side project / alone or in an organisation? I assimilate the former as theory, usually your work in this sort of project was not challenged by your pair. In an organisation, your work has been reviewed, challenged and you had gain real experience from that.

I don't know how to categorize the next case: A group side project. The work is challenged, but it is difficult to prove.

I can't offer specifics, but the way I typically evaluate jr. vs. sr. is whether the person can understand things at the conceptual level or not. Do they understand the design / architecture / reasons why things are/were done in a particular way, do they understand the benefits and downsides, and do they have knowledge about alternatives.

Junior developers almost always only know about concrete things they worked on previously. They typically have a hard time talking about anything other than implementation details.

A good senior developer is proficient in more than one languages, knows or figures out quickly the pros and cons of any technology. They have both depth knowledge in certain part of the development stack and breadth overall.

Assessing seniority by just number of years of experience, or knowing a hot technology doesn't make one a senior developer. A solid Aptitude + Attitude towards software development will make you a stronger developer, and that will also help you pick up any new tools, needed to get the job done!

Good Luck!

We define it as:

Junior: requires supervision.

Mid: individual contributor: can take stuff and get it done.

Senior: goes beyond their own individual code, more involvement in larger project (process, architecture, people, client, ...)

Technical skills required for senior: understand the fundamentals of networking and concurrent development, be able to effectively debug and troubleshoot. Tell me how a HTTP request works, be able to whiteboard a deadlock, be able to step through code with a tool (don't really care if it's VS or gdb).

Soft skills required for senior: help teammates help themselves by documenting and/or improving the development process and providing constructive criticism/best practice advice.

There's a rope making / knot tying analogy on the web for generally defining Junior<->Intermediate<->Senior<->Expert levels.

The chart I've linked draws distinction between Management / Professional Individual / Support Individual.

Word Doc: files.meetup.com/10036672/Leveling%20Charts.docx

I believe Software Developers fall under the Professional Individual Contributor class in the Leveling Chart.

A good junior dev asks lots of questions and eventually gets tasks done assigned to him or her on a somewhat reasonable timeline. Tasks get done progressively faster as they grow and they ask fewer and fewer questions (and usually said questions are unique, so no repeat questions for the most part).

That's a cultural thing. On a team of mine, I would worry if people weren't asking as many questions. It means they aren't finding the problems and pitfalls.

The questions should change, to be sure, but they shouldn't diminish unless we're not throwing progressively more complex tasks at them.

Junior developer: can use a computer to solve computer problems.

Senior developer: can use a computer to solve business problems.

This is the best resource that I could find on this topic, very clear: http://sijinjoseph.com/programmer-competency-matrix/

I consider a junior developer someone that is able to implement clearly defined specifications following existing patterns.

People with little or no experience in programming I wouldn't call junior developers, but perhaps apprentices.

Someone who identifies primarily with their favourite programming language is a junior. Someone who identifies with the problem domain they work in is a senior.

I hope I'm gonna stay Junior longer! I don't want to start using goto...

Without goto, you get to maintain several copies of your cleanup code, all different:

  int
  insane()
  {
      FILE *a = open("a", "r");
      if (!a) {
          return -1;
      }

      FILE *b = open("b", "r");
      if (!b) {
          fclose(a);
          return -1;
      }

      FILE *c = open("c", "r");
      if (!c) {
          fclose(a);
          fclose(b);
          return -1;
      }

      int rv = (do something with a, b, and c);

      fclose(a);
      fclose(b);
      fclose(c);
      return rv;
  }

Now here's an example where you only need to maintain one copy of your cleanup code:

  int
  reasonable()
  {
      FILE *a = NULL;
      FILE *b = NULL;
      FILE *c = NULL;
      int rv = -1;

      a = open("a", "r");
      if (!a) { goto out; }
      b = open("b", "r");
      if (!b) { goto out; }
      c = open("c", "r");
      if (!c) { goto out; }

      rv = (do something with a, b, and c);

  out:
      if (a) { fclose(a); }
      if (b) { fclose(b); }
      if (c) { fclose(c); }
      return rv;
  }

Avoiding goto gets impossible the second you start doing socket twiddling, or message generation. Yes, languages with context managers (Python's with blocks), RAII (C++ or Rust), or defer (Go) make this easier, but some of us are stuck writing C sometimes.

Of course in this case you can avoid both the repetition and the goto at the cost of more nesting:

  rv = -1;
  a = open(...);
  if (a) {
    b = open(...);
    if (b) {
      c = open(...);
      if (c) {
        rv = something(a,b,c);
        close(c);
      }
      close(b);
    }
    close(a);
  }
  return rv;

I wonder if there is some sort of program organization analog of Heisenberg's uncertainty principle, where the product of some measure of repetition, some measure of non-structured jumping, and some measure of nesting must be greater than a certain value?

It's primarily the ego of the person doing the labeling.

I'm a non-technical recruiter.

I get triggered when people confuse Entry & Junior developers:

Entry - Cant be trusted on their own - need hand holding.

Junior - Can be trusted on their own - like a slow mid-level developer - might need to check their code a bit after but generally know what they are doing with a little input from more senior developers in the team.

How would a non-technical recruiter know about developers and what's the difference between you and a technical recruiter?