
Ask HN: How do you define a junior developer? - guessmyname
For a web development position that requires basic knowledge of HTML, CSS, JavaScript companies can easily find junior developers, people with little to none experience in programming. But for system programming, how can you define a junior? Is it a person with experience as a programmer in other languages (say Ruby) but little to none experience in the language of the offer (say C++)? Or can someone without any programming experience at all find a job as a C++, Scala, Swift, Go developer?
======
mrmekon
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.

~~~
babyrainbow
>* 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.

~~~
pigpigs
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.

------
dccoolgai
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

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

~~~
dccoolgai
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".

~~~
Tloewald
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).

------
ska
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.

~~~
tsukikage
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.

------
beat
"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.

~~~
quantumhobbit
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.

~~~
beat
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.

~~~
siquick
"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

------
brad0
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...](https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html)

------
p4wnc6
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.

~~~
echelon
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.

~~~
quantumhobbit
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.

------
sidlls
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.

------
cauterized
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.

------
dasboth
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.

------
crispyambulance
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.

------
Isammoc
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.

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

~~~
Isammoc
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.

------
gorbachev
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.

------
recmend
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!

------
petervandijck
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, ...)

------
TYPE_FASTER
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.

------
genericone
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.

------
allsystemsgo
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).

~~~
ebiester
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.

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

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

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

------
facorreia
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.

------
gaius
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.

------
koenigdavidmj
The junior developer is blown around by every wind of shiny they know about.
They want to build an infinitely flexible framework for everything, even if
it's only being done once in your codebase.

They follow all the rules they were taught in school, like 'never ever use
goto in C', until their first code review by a senior developer, who shows
them that 'goto err' is much easier to understand than writing your cleanup
block before every single return statement.

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

~~~
koenigdavidmj
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.

~~~
tzs
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?

------
estevaoam
I have a different answer/approach to this question. Junior/senior is not only
experience-related but attitude and posture. Basically, a senior professional
is a more responsible, experienced and thinking-guided person.

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

~~~
echelon
No, it's not. Senior and junior convey real, tangible differences. A senior
development is more empowered by their experience and is much more effective
than a junior developer.

------
LouisRoR
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.

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

