A friend of mine working with an offshore team asked me to provide my definitions of the various stages of the developer life cycle.
What did Entry Level, Junior, Mid Level, and Senior developer mean to me, and what were my minimum expectations from each level.
Not the best approach, But at many companies its simply based on time served, they move up the ladder.
I think it's a combination of how long you have been working with a technology, how competent you are with it, and your ability to teach/assist those in the levels below you. E.G. Sr Developer should be helping those in Mid/Jr/Entry.
My definition however only ties it to a specific technology (or group of technologies).
What they ought to mean:
What they mean in most businesses:
IMHO, an entry-level programmer is just beginning, and learning his or her way around your code base. A junior can write classes, modules, etc. to specifications. A middie can look at the "higher level" architecture view, and write specifications for classes, modules, etc. A senior can do all of the above, as well as managing and/or mentoring lower-level programmers.
Entry: Someone who has a job in this industry for the first time. They might have technical degree, but more than likely don't know what platform (java, .Net, c++, etc..) and need to be trained.
Junior: Someone with 1-3 years of experience that has working knowledge on their platform. They might not yet no the full extent or capabilities of the platform, but should be able to do some projects without help of others, but also seek advice from others on their team.
Mid-Level: Able to work on large projects and make technical/design decisions about the product. Helps mentor junior developers on how to use the platform properly as well as the business domain. Usually as 3-10 years of experience.
Senior: 7+ years of experience working on the platform and/or the industry. These people could be team leads, product owners, or architects.
We have similar gradings:
Straight out of education or off the street; shows programming ability, but lacks language\business experience. Someone we want to spend money and time on to train up. Much input needed to this person.
Has some business experience and knows the development language, but maybe not the arena we're working in. Needs more experience and training. Can work on small developments by themselves, but need supervision and guidance.
Knows the business arena and has good knowledge of the development language. Can work on small developments unsupervised, larger developments with guidance and be part of a team for large developments. Requires code reviews and training to get to next level.
Someone who knows a wide range of the business arena or is a specialist in an area. Expert in language. Can work on most levels of code unsupervised and requires minimal guidance. Can guide lower grades. Interested in furthering product and practices as well as 'doing the job'. Uses initiative.
We then have two further grades:
For those wanting to branch out into management and leave the coal-face behind.
For those wanting more freedom and control, but still be developing and\or involved with the direction of the product at a technical level.
To progress up the grades requires experience mainly.
Must develop small packages to the correct standards. Must be able to demonstrate some knowledge of the business arena. Basically, they must show willing to learn and ability to learn. Usually 1-2 years.
Must be able to demonstrate that they code to standard most of the time and can work on larger pieces of development. Must show good abilities in the business arena (i.e. by working with internal\external customers). Usually 1-3 years. Sometimes forever.
This one is the difficult one - the person must show command of the language, be able to develop larger projects, deal with customers and be starting to guide others. In simple terms, this person is showing signs of being a guru. Senior level is an elite status.
This tends to be a co-operative move from both the person and the business. They must show willingness to move on and tackle new areas. Many do not get to this - they're happy being a guru.
We are trying to adopt an agressive way to evaluate and promote our programmers:
Programmer Competency Matrix (IndianGeek)
Programmers are being called to auto-evaluate thenselves into this matrix under seniors help. With an well defined and broad matrix of evaluation people know exactly what they can do to step up the ladder.
Ideally;
Someone a while back posted a link to this matrix, which I think defines it at a particular competency: http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm
Ultimately, this is hard to set ground rules based on "years of experience". A person with one year of experience could be an entry level programmer, or could be a middle level programmer, depending on how they apply themselves. A telling quote, I heard while I was a junior programmer from a senior programmer who was interviewing candidates: "Just because the person has 10 years of programming experience, doesn't mean they senior level. It could be that they have 1 year of experience ten times." That made a lot of sense to me. A person should continuosly build on previous knowledge, in a way analogous to the sciences, math, or engineering.
That said, here's my go at answering your questions directly:
1. An entry level programmer is someone who has been trained in programming but has no experience. The whole act of being on a project and solving problems is new, and they need a lot of hand holding.
2. A junior programmer has a sense of the system he is playing in, in that he knows the basic process. They know where to fine things, and how to solve the basic problems without supervision. Anything more requires supervision.
3. A mid-level programmer can see the big picture, and do decently complicated tasks without supervision. Additionally, a mid-level programmer should be able to resolve most scenarios / issues that come his way.
4. A senior-level programmer knows the system (business and code). And like a good author, knows when to bend the rules to accomplish something critical. Note, this isn't an excuse for lack of discipline, but someone who understands nuances of the issues, and can account for it in the decisions they make. Often these individuals are responsible for many components or systems that are interwoven. Often these individuals are responsible for mentoring or aiding others.
When I might promote someone from one level to another would depend on a lot of situations. Some businesses don't care if the programmer has good interpersonal skills if he is a guru of some sort -- I'm more pragmatic, but I also like smaller business environments. A small business environment doesn't have as much room for a the anti-social super programmer, unless he is the one who makes the business critical software all by himself. Even then it comes at a cost. What I would look at is:
1) How does the person fit in the Matrix (first link). If s/he is level 2 in enough areas, I'd consider as an option for advancement to senior level.
2) Does the person show leadership in either technical or business or interpersonal area? If yes to 1 but not to 2, I'd take the person aside to have a discussion to see what is going on. If the person is just so busy he/she can't do anything in that area, that is understandable, if the person just has no drive, then stay at mid-level.
Ultimately, if you think of the levels as a sort of bell curve, perhaps I'm weird, but I see 50% at entry / junior, 25% at mid-level, 24.9% at senior-level, and 0.1% at guru level. Guru is someone that is sooooo good that people outside his/her organization benefit and learn.
We have something similar to the following at my company, note, technical-graduates tend to come in at Engineer level as they're employed for their subject-mater expertise.
not working on anything deliverable, doing their apprenticeship - do not level unattended for long periods of time.
same as above, but now working on your product
can be tasked with work, but usually in a small self-contained area. Usually needs someone senior to review designs, approach, code, etc. Should be able to be left on own for short periods (e.g. they should now know how to ask for help)
a few years experience (anywhere from 2 to 6 years), a few projects under their belt (hopefully experienced a bad project by now, starting to have stories in their War-Chest). Can generally review the work of juniors. Can tell management when schedules are wrong or expectations are too high. Awareness of the whole product and can contribute towards the overall design. Can sometimes be a team-leader.
Generally a team-leader or very experienced engineer in a specific field (5-8 years). Understands the needs of the project, product and company. Knows how to get on with work without management micromanaging them. This is as high as many will get. Beyond here it's management only.... :-(
Technical/Project Manager or VERY experienced engineer (graduate and 8-10 years+ work experience). If still technical, should be able to jump into a project they don't know with minimal ramp up time (as they should know the domain/areas well).
A "software engineer" is first of performing "engineering" activities, who is a worker.
He accumulates area-panning engineering, managing, work-political know-hows during time.
I can see Junior or Senior can be defined in teams of loose or strict constrained meanings.