Levels and expectations
Junior and SDE2
Juniors finish well-scoped work cleanly. SDE2s own features end to end without someone breaking the work into steps.
At junior level the job is to become useful inside an existing machine. At SDE2 the company trusts you as a default independent contributor. Same domain can sit at either level. The difference is the axes: how defined the problem is, and whether "done" includes rollout and follow-up.
Junior / SDE1
Work arrives reasonably well-defined: a ticket with acceptance criteria, a bug with a repro, a small feature whose design someone else sketched. You implement, ask when stuck, learn the codebase and the team's norms, and grow independence week by week.
| Axis | Junior |
|---|---|
| Scope | Tasks and small features inside one area. You are not expected to invent the project. |
| Autonomy | Guidance on how for unfamiliar work, and sometimes on what. |
| Complexity | Local reasoning — one service, one UI surface, clear APIs. |
| Influence | Mostly your own diffs. You start reviewing peers carefully. |
Example
A junior owns "add rate-limit headers to the public API responses" after a senior writes a short design note. They find the response middleware, add the headers, write tests, open a PR, fix review comments, and watch the deploy. They did not choose the approach or the rollout plan — and that is appropriate.
The failure mode at this level is not "asks too many questions." It is silent stuckness (days with no update) or fake progress (activity without a path to done). The other failure mode is refusing well-scoped work because it feels beneath you; juniors get sharp by finishing real tickets cleanly.
SDE2
You still have a manager and tech leads, but for a normal feature you should not need someone to break the work into steps or sit with you on every design choice.
| Axis | SDE2 |
|---|---|
| Scope | Features and small projects end to end — design input, implementation, tests, rollout, monitoring, follow-ups. |
| Autonomy | Low guidance on how. The problem is named; you clarify edge cases. You do not invent the product strategy. |
| Complexity | Solid engineering inside known patterns — new endpoints, data model changes, careful migrations. |
| Influence | Your team's code and practices. You review others' designs and mentor juniors informally. |
Important
The SDE2 bar is reliable delivery of owned features, not "wrote a clever algorithm once." Reliability means: you estimate with humility, you surface risk early, you leave the code operable, and people believe your "done."
Example
Same API surfaces. An SDE2 is asked to "reduce abuse on the public search endpoint." They pull metrics, propose token-bucket limits plus better client errors, write a short design, implement, add dashboards, roll out behind a flag, and write a runbook note. Nobody had to assign the subtasks.
Compare that to junior ownership of a pre-scoped header change. Same domain; different axis scores — especially autonomy and scope. "End to end" means the user-visible outcome, not just the merge.
Common mistakes
- Silent stuckness. Days with no update. Ask early; that is junior-appropriate.
- Treating SDE2 as cleverness. One clever PR does not replace a year of reliable delivery.
- Stopping at merge. If nobody is watching the deploy or the dashboard, the feature is not owned.
Check yourself
You are asked to add a header that a senior already designed. Which level is that work?
Junior-shaped: the approach and rollout were chosen for you.
You are asked to "reduce abuse on search" with no subtasks. What does "done" include at SDE2?
Design, implementation, tests, rollout, dashboards and a runbook — the user-visible outcome.
Key takeaways
- Junior: well-scoped tasks, learning the system, growing independence. Ask; do not go silent.
- SDE2: owns features end to end with little how-guidance; people believe your "done."
- Same codebase, different axes. Headers vs "fix abuse" is the contrast.
- Reliability beats a single clever algorithm.
Further learning
Next, the tilt from executing features to owning ambiguous problems: senior and staff.
Related
What the levels mean
Junior, SDE2, SDE3 and staff: scope, autonomy, impact and influence at each level.
The four leveling axes
Scope, autonomy, technical complexity and influence — the four questions every engineering ladder is really asking.
Senior and staff
Senior owns ambiguous multi-quarter problems and multiplies the team. Staff is a different job shape, not a louder senior.