Other than title and pay, what is the difference?

  • What different responsibilities do they have.

  • How knowledgeable/experienced are they?

  • What is the basic measure to determine where a developer fits into this basic structure?


9 Answers 9


This will vary but this is how I see it at a place large enough to have distinctions between types of programmers.

I would say entry level and Junior are the same thing. They are just out of school and have less than two years of work experience. They are assigned the least complex tasks and should be supervised fairly closely. Generally they know about 10% of what they think they know. Usually they have not been through the whole development cycle and so often make some very naive choices if given the opportunity to choose. Sadly many of them don't actually care what the requirement is, they want to build things their way. They often have poor debugging skills.

Intermediate level is where many programmers fall. They have more than two years experience and generally less than ten, although some can stay at this level their whole careers. They can produce working code with less supervision as long as they are assigned to relatively routine tasks. They are not generally tasked with high level design or highly complicated tasks that require an in-depth level of knowledge. They may be tasked with the design of a piece of the application though, especially as they are in the zone to become a senior developer. They are good at maintenance tasks or tasks where they can focus on just their piece of the puzzle, but are not usually expected to consider the application as a whole unless working with senior developers or being prepped for promotion to senior. They can usually do a decent job of troubleshooting and debugging, but they have to really slog through to get the hard ones. They do not yet have enough experience to see the patterns in the problems that point them to the probable place they are occurring. But they are gaining those skills and rarely need to ask for debugging help. They have probably been through the whole development cycle at least once and seen the results of design problems and are learning how to avoid them in the future. Usually they tend to be more likely to take a requirement at face value and not push it back when it has obvious problems or gaps. They have learned enough to know what they don't know and are starting to gain that knowledge. They are the workhorses of the programming world, they deliver probably 80-90% of the routine code and maybe 10% of the very difficult stuff.

No one who is senior level even needs to ask this question. They are experts in their chosen technology stacks. They are given the hard tasks (the ones nobody knows how to solve) and often get design responsibilties. They often work independently because they have a proven track record of delivering the goods. They are expected to mentor Junior and intermediate developers. Often they are amazing troubleshooters. They have run into those same problems before and have a very good idea of where to look first. Seniors often mentor outside the workplace as well. They generally have at least ten years of experience and have almost always been on at least one death march and know exactly why some things are to be avoided. They know how to deliver a working product and meet a deadline. They know what corners can be cut and what corners should never be cut. They know at least one and often several languages at the expert level. They have seen a lot of "hot new technologies" hit the workplace and disappear, so they tend to be a bit more conservative about jumping on the bandwagon for the next exciting new development tool (but not completely resistant to change - those would be the older Intermediate developers who never make the leap to Senior). They understand their job is to deliver working software that does what the users want, not to play with fun tools. They are often pickier about where they will work because they can be and because they have seen first hand how bad some places can be. They seek out the places that have the most interesting tasks to do. Often they know more about their company's products than anyone else even if they have been there only a few months. They know they need more than programming knowledge and are good at getting knowledge about the business domain they support as well. They are often aware of issues that juniors never consider and intermediates often don't think about such as regulatory and legal issues in the business domain they support. They can and will push back a requirement because they know what the problems with it will be and can explain the same to the laymen.

  • 2
    is there a Title (in English) to the "Intermediate level" Google translator uses "Full developer". But it's not a valuable source =) Commented Nov 27, 2012 at 13:31
  • 23
    Excellent, story-like explanation. I enjoyed reading it. Commented Apr 6, 2014 at 8:11
  • 1
    Thanks for this explanation. I am self-taught in iOS dev (no comp-sci education) and have released my first app which has some non-trivial features (i.e CRUD's JSON, some social components, good design). I don't think I am a great programmer but I did write the app back to front and understand what it takes to ship. Where would you place someone like me, hypothetically?
    – SamYoungNY
    Commented Feb 10, 2016 at 18:24
  • 1
    @NYCTechEngineer, well stack overflow comes to mind. Also local user groups, blogging, writing articles and books.
    – HLGEM
    Commented Feb 10, 2016 at 18:53
  • 1
    @BrianHaak Thx - it's interesting what you say. Since last year I've worked on a much larger project than before. I've gotten that feeling of taking a look at code I wrote just a few months ago and saying "wtf? Who thought this was a good idea?" :) - Starting this project from a small kernel into a project that can be extended easily & also able to accommodate non-devs who want to add content has forced me to think about higher level structure. Pairing w a more experienced programmer showed me that I'm missing a lot of opps. to use abstractions. I also have trouble w namespace.
    – SamYoungNY
    Commented May 4, 2017 at 3:43

Entry Level - must give them explicit instructions, check everything they do, little or no design responsibility, no analysis responsibility

Junior - less explicit instructions, less checking, some minor design and analysis responsibility; helps the entry-level people find the compiler and use the repository

Senior - major design and analysis responsibility, is expected to correct oversights on his/her own, little/no checking, little/no instructions; helps the junior-level people learn/improve analysis and design skills

  • 20
    Nice, except I don't know that I completely agree with "no checking/instructions" for senior level. Unless you are not working on or with a team, no one should completely be an island. Commented Oct 26, 2010 at 20:51
  • @WonkotheSane we have one who merges codes with errors without any codeReview or pull request. Doesn't discuss much about app architecture other than to just use observation pattern everywhere. Makes all decisions all by himself so he wouldn't adapt to anything new. All because he is an island himself. He isn't in it. He is the island :(
    – Honey
    Commented Dec 24, 2016 at 16:35

Really, I think it just comes down to how long you have been on the job. If you have 10 years experience you are a senior dev, if you are a graduate then you are probably entry level. I have seen many 'senior' dev's who could hardly code and didn't really know what they were doing and many junior dev's who were fantastic.

  • 7
    This echoes my experiences. "Senior" means time with the company and usually nothing else; skill doesn't factor in one iota. I've worked with plenty of "senior" developers (and managers for that matter) who knew nothing about software beyond trial-and-error development but had been with the company for 5+ years, or was the very first programmer hired when the place was started, and so got promoted due to tenure. Commented Jul 27, 2011 at 15:10

I think the old school craftsman slots of apprentice, journeyman and master fit into these slots well for entry level, junior (or just no prefix) and senior.

Someone entry level is given relatively simple tasks that do not have profound consequences and their work is checked by a junior or senior. Over time they get more responsibility and are given more complex tasks, learning the ropes along the way.

At a junior (or just the removal of "entry level" / "junior" from the title / description) you have completed your apprenticeship and have covered the major areas of development for your company, having dipped into each major area so that you are familiar with each of them. You now help provide guidance and input for the apprentice equivalent, but your own work is still reviewed by the master / senior, though perhaps not as much as when you were a junior.

Over time and the delivery of successful projects you eventually become senior. At a senior level you have mastered everything that is covered in your area, covering the entire development process and all the tools and technologies that are involved. You are empowered to make significant technical decisions and are expected to provide insight to management into the software development process.

So, given those guidelines you should be able to look at a person or a position and determine which of the three bins they land in.


It's going to boil down to the company's expectations of the programmer.

If I'm the hiring company and I hire an Entry Level programmer, I know that that person knows next to nothing and we're going to assume he/she needs to learn everything. If I hire a Senior level person, in theory, they'll be self sufficient, from a technical stand point.


This strictly depends on the company. But the words are fairly obvious: entry level is someone who is just entering the field, junior is someone who is beyond entry level and knows there way around a few languages technologies. Lastly senior are those who are more in charge of the project and sit at a higher level. They can usually delegate as much as they code.

  • I get this, but at what point are you "beyond entry level" or "beyond junior"? If you are always learning then everyday you are beyond what you were the day before.
    – JD Isaacks
    Commented Oct 26, 2010 at 19:43
  • Entry level is easy, but I am looking more for examples of experience/knowledge that would suggest junior or senior.
    – JD Isaacks
    Commented Oct 26, 2010 at 19:48
  • Like I said this depends on the company, the context of the technology/languages in question and more specifically its a matter of opinion unless you are talking about official job titles. I do not think I will ever consider myself an expert in any language unless I wrote the darn thing myself.
    – Chris
    Commented Oct 26, 2010 at 19:53
  • Additionally, if you are at a company look at jr, sr developers and compare/contrast yourself to them. This is a good gauge in context specific to said company.
    – Chris
    Commented Oct 26, 2010 at 19:54

As most have said, it varies from company to company, and job to job.

For instance, I once worked at a company that considered anybody who worked there for more than 5 years a "Senior Software Engineer". At the other extreme, another place I worked had very stringent definitions (and associated pay scales).

Some places may consider "entry level" and "junior" to mean the same thing.

It can vary based on years of experience, general knowledge, specific knowledge (i.e. knowing the features of a certain language), managerial and/or leadership experience, all combinations thereof, and certainly much more.


I'm going to go with the really simple answer here: senior developers (in general) are people that can see the forest for the trees. They think beyond just the immediate issue in front of their faces and have an understanding of what architectural changes could or should happen as a result of fixing the problem they are faced with.

Most software companies I've seen have the entry level people doing the day to day coding while the senior devs are overseeing what the new people are doing and tackling the really ugly, thorny issues.

Obviously this is just my opinion, and not a hard-and-fast rule. YMMV.


Simply put and from personal observations found on job posting sites and only regarding experience levels.

Entry = Your new probably your first job.

Junior = Your good but not supposed to be the best, you also usually have less then 5 years and more than 2 years experience.

Senior = You are supposed to be the best and do have more than 5 years experience.

  • You missed an intermediate. Commented May 3, 2017 at 19:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.