Your career map: the eight levels of this course
On This Lesson 11 topics
Lesson Overview
This course is not one long list of topics. It is a path with eight levels, from your very first lesson to the kind of work done by people who design large systems for whole organizations. Knowing the map early helps you in three ways: you can see where you are, you can see what the next step asks of you, and you can choose which direction you want to grow.
The eight levels, in order, are Beginner, Junior, Mid, Senior Grade C, Senior Grade B, Senior Grade A, Staff, and Solution Architect. Each level adds something. The most useful way to remember what it adds is scope: first you are trusted with a task, then a feature, then a service, then a system, and finally work that spans many teams. Technical skill grows along the way, but so do two things that no tutorial can fully teach: judgment (choosing well when there is no single right answer) and communication (making others understand and agree).
The house picture continues. At the start you carry bricks and follow instructions. Later you build a whole room, then a whole floor, then you help plan the building, and in the end you may plan a neighborhood. The larger the scope, the more your work consists of decisions and conversations, and the less of it is laying bricks, though a good planner still knows how bricks are laid.
Two honest notes before we begin. First, titles and ladders differ between companies. The eight levels here are this course's own map, and they will not match every employer's job titles. Second, no course replaces real experience in production, especially at the senior levels. The course can teach the ideas and give you practice; it cannot give you the years of running real systems with real users. Anyone who promises otherwise is selling something.
This lesson builds on the roles lesson (the roles you can grow into) and on the previous lesson (the path a feature takes, which is what you will do at every level, with growing scope).
Learning Objectives
By the end of this lesson you will be able to:
- Name the eight levels of this curriculum in order.
- Describe in one or two sentences what each level adds over the one before.
- Explain the idea of growing scope: task, feature, service, system, many teams.
- Explain why seniority is more than deeper technical knowledge, and name the two other things that grow.
- Explain why some skills can only come from real production experience.
- Explain that Staff and Solution Architect are related tracks rather than automatic next steps.
- Pick a level you want to reach and write a short, reasoned note on what it would ask of you.
Written Explanation
The eight levels
| # | Level | Typical scope | In one sentence |
|---|---|---|---|
| 1 | Beginner | A small program | Learn the foundations: how computers, software, and the web work; write Java console programs; use Git; understand relational databases |
| 2 | Junior | A task or a feature, with guidance | Implement, test, secure, and deploy a backend application inside an existing design |
| 3 | Mid | A service you own | Design and own moderately complex services; troubleshoot production; reason about performance and reliability |
| 4 | Senior, Grade C | A significant subsystem | Lead design and delivery of a subsystem; make architecture decisions; manage technical risk; guide others |
| 5 | Senior, Grade B | Work across several teams | Lead multi-team technical initiatives; evolve existing architectures safely; balance speed, cost, and long-term health |
| 6 | Senior, Grade A | A major product area | Shape the technical direction of a product area; establish standards; influence several teams without formal authority |
| 7 | Staff | An organization | Find systemic technical problems; create leverage for many teams; lead strategic programs |
| 8 | Solution Architect | A complete solution | Design a whole solution from business requirements to applications, integrations, infrastructure, security, data, operations, delivery, and cost |
The wording of the right-hand column is a close paraphrase of the outcomes written for each level in this course's roadmap. The "typical scope" column is a simplified summary to help you remember the ladder.
Level 1: Beginner
Where you are now. The goal is to build the base that everything else stands on: understand what computers and software are, how the web works, how engineers work in teams (this module), and to write real Java programs. You will use Git to save and share your work, and learn how relational databases keep data. By the end you should be able to explain how a web application works from the browser down to the data.
What it adds: the ability to read and write simple programs and to talk about how systems fit together. Your scope is a small program, and your biggest challenge is learning to think precisely.
Level 2: Junior
At Junior level, you start building real backend services, usually with a framework (a ready-made foundation that handles common jobs so you do not write them from scratch; the course uses the Spring ecosystem for Java). You learn to implement features, test them, secure them, and deploy them, all inside a design that already exists. You will also meet collaboration tools and handle straightforward production defects with guidance.
What it adds over Beginner: building working backend applications as part of a team, with other people's code around yours. You work on a task or a feature, and a more experienced colleague usually helps with the large decisions. In terms of the feature path from the last lesson, you do code, tests, and review very well, and you take part in the other stations.
Level 3: Mid
A Mid-level engineer owns a service: decides how it is built, keeps it healthy, and answers for it. The skills now go deeper: how the Java platform runs your code, how to find performance problems, how to troubleshoot in production, and how to make informed technical trade-offs.
What it adds over Junior: ownership and independence. Instead of "implement this feature as designed", the request becomes "make this service reliable and fast enough", and you work out what that means. Production experience starts to matter a lot: the first time a service you own fails at night teaches things no book does.
Level 4: Senior, Grade C
The first senior grade centres on system ownership. You lead the design and delivery of a significant subsystem, make architecture decisions that others rely on, identify and manage technical risks, and help less experienced engineers grow. Early topics here (as the module titles in the roadmap show) include turning vague goals into clear requirements and the trade-offs between quality goals such as speed and safety.
What it adds over Mid: design leadership and risk management. You think about the system's whole life, about what could go wrong, and about the people building it.
Level 5: Senior, Grade B
Grade B is about cross-team design. You lead technical work that involves several teams, evolve existing architectures safely (not by rewriting everything), and balance delivery speed, cost, and long-term maintainability. Patterns that look attractive in articles are examined as trade-offs, with costs, rather than as upgrades.
What it adds over Grade C: working across team boundaries. Technical decisions now need agreement from people who do not report to you, so persuasion and clear writing matter as much as design skill.
Level 6: Senior, Grade A
Grade A is technical leadership. You shape the technical direction of a major product area, resolve difficult architecture problems, establish engineering standards, and influence several teams without formal authority. The thinking widens from systems to the organization: how teams and systems fit together, and where the shape of the organization and the shape of the software disagree.
What it adds over Grade B: direction and standards. People follow your technical lead because they trust your judgment, not because you are their manager.
Level 7: Staff
Staff engineers work at the scale of an organization: they find problems that cut across many teams, create leverage (work that makes many people more effective), lead strategic engineering programs, and improve the effectiveness of multiple teams. The course treats Staff as a related track, not a mandatory step after Grade A.
What it adds: leverage and a long time horizon. A Staff engineer picks problems by asking "what changes outcomes for many teams per unit of effort?", and is often not on any one team.
Level 8: Solution Architect
A solution architect designs a complete solution that connects business requirements, applications, integrations, infrastructure, security, data, operations, delivery, and cost. The course also treats this as a related track, not an automatic step after Staff. Architects work between business people, delivery teams, and other parties, so communication and trade-offs dominate.
What it adds: the end-to-end view of a solution and its business context. An architect who can no longer read code or does not understand operations makes plans that do not survive contact with the real system, which is why the course puts the architect level last, after the engineering levels.
The idea of growing scope
Look at the "typical scope" column again. A useful way to read it is as a series of questions you can answer:
- Beginner: Can I make a small program do what I intend?
- Junior: Can I deliver this feature so that it works and others can maintain it?
- Mid: Can I keep this service healthy and make good choices about it?
- Senior: Can I design and lead a larger system, and bring other people along?
- Staff and architect: Can I improve how many teams, or a whole solution, work?
Larger scope means more people affected by a decision, a longer time before you know whether it was right, and more of your time spent on explaining rather than typing. Notice that you do not stop doing the earlier work; you add to it. A good Senior engineer still understands a loop, a test, and a database query.
Technical skill is necessary, but not enough
Many beginners believe that senior simply means "knows more technical things". The truth is more interesting. Three things grow together:
- Technical depth and breadth: more tools, more internals, more patterns.
- Judgment: choosing well when requirements conflict and nobody can prove which option is right. For example, deciding whether a quick fix is acceptable or whether it will cost the team later.
- Communication: writing clearly, explaining trade-offs to people who are not engineers, giving and receiving feedback, and getting agreement.
At the junior level the first dominates. At senior levels the other two often decide whether a piece of work succeeds. Two engineers with the same technical skill can differ greatly in impact because one can explain a design clearly, spot a risky assumption early, and say a respectful "no" to a bad idea.
What no course replaces
The course teaches ideas and gives practice, but some skills grow only from real production experience:
- Seeing how a system behaves under real load and real mistakes.
- Being responsible when something fails, and learning from it afterward.
- Living with a decision for years and seeing its consequences.
- Working with real teams, real deadlines, and real disagreements.
Treat the later levels of the course as a map of what to learn and what to look for, and get real experience along the way, with a job, an internship, open-source contributions, or serious projects. The senior levels of the course also use role-played scenarios; they are practice, not a substitute.
Using the map for yourself
You do not have to aim for the last level. Many excellent careers stay at Senior; some people move into management; others deepen into one specialty. The map is for choosing and for avoiding surprises. A good habit is to ask, at each level: what does the next level ask that I cannot yet do? Then pick one concrete step, such as "write a design note for my next task" or "ask to join the on-call rotation as an observer".
Examples
Example 1: the same feature at three levels (simple)
The feature: "customers can reorder a previous order".
- Beginner: can write a small Java program that prints a list of past orders and lets you pick one.
- Junior: implements the reorder endpoint in the existing backend, writes tests, and responds to code review.
- Mid: decides how reorders interact with price changes and unavailable items, makes sure the endpoint is fast with many orders, and watches it in production.
The idea is the same. The scope of the decisions grows.
Example 2: reading a job post against the map (practical)
A job post says: "Junior Java backend developer. Required: Java, Spring Boot, SQL, Git, REST APIs, unit testing. Nice to have: Docker, basic cloud knowledge."
Place each skill on the map. Java, SQL, and Git belong to Beginner. Spring Boot, REST APIs, and unit testing belong to Junior. Docker and cloud appear as "nice to have", which a Junior may add on the job. The post asks for the end of Beginner and the start of Junior, which is exactly what the title promises. (This is an invented post to show the method. The lab for this module asks you to do the same with real ones.)
Now read a different post: "Senior backend engineer. Lead the design of the payments subsystem, mentor two engineers, decide on trade-offs between consistency and speed, represent the team in architecture reviews, be on call." Notice that most of the verbs are about design, risk, other people, and responsibility, not about a language. That is the shift in scope.
Example 3: two engineers, same skills, different impact (realistic)
Two Mid-level engineers have the same technical skills. A production problem appears: a service slows down every evening.
- Engineer A quietly tries ideas for two days, changes things without writing anything down, and then says "fixed". Three weeks later the problem returns and nobody knows what was changed.
- Engineer B writes down what they saw, what they tried, and what worked. They tell the affected teams what to expect, add a measurement so the next slowdown is visible, and ask a teammate to review the fix.
Both fixed the problem today. Only B left the team better prepared. This is judgment (writing and measuring) and communication (telling people) at work, and it is the difference that matters more and more as the levels rise.
Backend Insight
Backend work makes the growth in scope visible, because a backend sits in the middle of many other things:
- A task is a change to one function or a rule. A feature crosses a few parts of the service. A service involves its data, its users (often other programs), its operation, and its cost. A system is several services that depend on each other. Many teams means that one change needs agreement from people with different priorities.
- Operations come in earlier than you might think. Mid-level work already includes troubleshooting production and thinking about reliability. If you enjoy the operational side, the SRE role from lesson 2 is a natural neighbor.
- Data decisions last longest. A mistake in how data is stored can follow a company for years, so seniors spend time on data and boundaries, not only on code.
- Seniors write. Design notes, decision records, and review comments are major outputs. Practice clear writing from the start.
So when you do a small exercise in the Beginner level, remember that the larger the system grows, the more the same habits (clarity, precision, checking, communicating) carry the weight.
Common Mistakes
Mistake 1: Assuming seniority means only deeper technical knowledge
- Incorrect: "To become senior I just need to learn more frameworks."
- Correct: "I need deeper technical knowledge, and also better judgment and communication, and real experience with production systems."
Mistake 2: Treating the levels as a fixed timetable
- Incorrect: "Every level takes exactly one year, and I will be a Senior in five."
- Correct: "The levels describe what you can do. How fast you reach them depends on practice, the work you are given, and your environment."
The course does not give a promise of time or salary for any level, and neither should you expect one.
Mistake 3: Believing every engineer must reach Staff or Architect
Those two are related tracks, and many strong engineers choose to stay as senior engineers, to move into engineering management, or to specialize. Pick based on the work you enjoy.
Mistake 4: Skipping the early levels
It is tempting to jump to "architecture" because it sounds important. But architects who cannot read code or have never operated a system make poor decisions. The levels build on one another.
Mistake 5: Ignoring production experience
Courses, books, and videos cannot replace running real systems. Seek experience early: small real projects, internships, open-source work, and, once employed, ask to take part in releases and on-call duties.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. Write the eight levels of this course in order from memory.
Show solution A1
A1. Beginner, Junior, Mid, Senior Grade C, Senior Grade B, Senior Grade A, Staff, Solution Architect.
A2. Complete the scope ladder: task, ___, service, ___, many teams.
Show solution A2
A2. Task, feature, service, system, many teams.
A3. What two things besides technical skill grow as you go up the levels?
Show solution A3
A3. Judgment and communication.
Level B: Application
B1. In one or two sentences each, say what Junior adds over Beginner and what Mid adds over Junior.
Show solution B1
B1. Junior adds building real backend applications as part of a team, with testing, security, and deployment, using a framework and within an existing design. Mid adds ownership: you decide how a service is built, keep it healthy in production, and reason about performance, reliability, and trade-offs.
B2. Read this invented job post and say which level it fits and why: "Design and own our notifications service. Decide how it scales, handle its production problems, and make sure it stays reliable. Strong Java and database knowledge required."
Show solution B2
B2. Mid. The post asks for ownership of a service, decisions about scale, handling production problems, and reliability, which are the Mid-level responsibilities. A Junior post would ask for implementing features under guidance.
B3. A friend says: "Senior engineers just know more tools than the rest of us." Write a short, friendly reply that explains what else is going on.
Show solution B3
B3. Example: "Tools matter, but they are only part of it. Seniors also make better decisions when things are unclear, and they explain those decisions so other people can agree or help. A senior with fewer tools but good judgment and clear communication often has more impact than someone who knows every tool but works alone." Any friendly answer that mentions judgment and communication is fine.
Level C: Challenge
C1. Staff and Solution Architect are called related tracks, not mandatory steps. Explain in your own words what that means and why a person might choose to stay at Senior.
Show solution C1
C1. Related track means that Staff and Solution Architect are different kinds of work, built on senior engineering experience, not simply "the next rung". A person might stay at Senior because they enjoy building and owning systems, because they prefer to stay close to the code, or because the jobs of Staff or architect (many meetings, influence across teams) do not appeal to them. Both choices are legitimate.
C2. Choose the level you want to reach and write about 120 words covering: what it adds, one thing you can already do toward it, and two things you do not yet know how to do. Be honest about the gaps.
Show solution C2
C2. Answers will vary. A good one names the level, says what it adds in scope (for example "owning a service"), names a true current strength (for example "I can write small Java programs"), and honestly lists gaps (for example "I have never deployed anything", "I have never read production logs").
Mini Challenge
Make your own one-page career map. Draw eight steps (a staircase works well) and, beside each, write one line in your own words about what that level adds. Then mark three things:
- Where you are today.
- Where you would like to be in your first job, and which job title you would search for.
- One production-like experience you can get in the next three months that this course cannot give you (for example a small project that you deploy and keep running for real users, or a contribution to an open-source project).
Check your work: the eight levels are in order, the lines describe scope rather than only tools, you mention judgment or communication at least once, and your three-month step is specific enough that you could start it this week.
Summary & Next Lesson
Key takeaways
- The eight levels are Beginner, Junior, Mid, Senior Grade C, Senior Grade B, Senior Grade A, Staff, and Solution Architect.
- Scope grows: task, feature, service, system, many teams.
- Technical skill is necessary but not enough. Judgment and communication grow in importance.
- Staff and Solution Architect are related tracks, not automatic next steps.
- Real production experience cannot be replaced by a course, so look for it early.
- Titles differ between companies, so read job posts for responsibilities, not just names.
Next lesson
The last lesson of this module is a demo, "Demo: a day in a backend engineer's workflow, walked through". You will follow one ticket through a whole working day: asking a question, changing code, running tests, opening a pull request, fixing a failed check, and watching a release.
Self-check
- Name the eight levels in order.
- What does the scope ladder look like?
- Name two things besides technical skill that grow with seniority.
- Are Staff and Solution Architect mandatory steps after Senior?
- Why can a course not give you everything needed for senior work?
Show answers
- Beginner, Junior, Mid, Senior Grade C, Senior Grade B, Senior Grade A, Staff, Solution Architect.
- Task, feature, service, system, many teams.
- Judgment and communication.
- No. They are related tracks that build on senior engineering experience.
- Some skills, such as seeing how systems behave under real load and living with design decisions over years, only come from real production experience.
References
- This course's own roadmap (the Java Backend Engineering Mastery roadmap data in this site's repository), which I read for the name, audience, and written outcome of each of the eight levels. The right-hand column of the level table paraphrases those outcomes. The "typical scope" column and the task-feature-service-system-teams ladder are simplifications for teaching, not an industry standard.
- Titus Winters, Tom Manshreck, and Hyrum Wright (eds.), Software Engineering at Google, chapter 1. Supports the broader point that engineering involves time, team scale, and trade-offs, which is why judgment and communication become more important as scope grows.
- I did not find an authoritative industry standard for these levels or for what each title means, and companies use different ladders, so the lesson says so. No salary, timeline, or hiring statistics are given because I could not verify any.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.