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?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.
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
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.
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.
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.