Table of Contents

Return to the Software Development Career Playbook

Employers define junior, mid-level, and senior work differently. Compare your current role framework with evidence from delivery, debugging, review, design, operations, communication, mentoring, and domain knowledge.

What Actually Changes Between Levels

Many frameworks distinguish levels through scope, support, impact, or complexity. The table below is an example for comparison, not a universal ladder.

LevelWhat You OwnHow You Get There
JuniorDefined tasks with review supportLearn the codebase, deliver tested changes, and use feedback
Mid-levelA feature or service area with agreed supportPlan, review, debug, and explain trade-offs
SeniorA broader system, domain, or team concernDesign, reduce risk, review, mentor, or coordinate as the role requires

From Junior to Mid-Level

One employer might evaluate reliability and independence in a junior-to-mid review. Another might use a different level name or evidence set.

Possible evidence to compare with the written framework:

  • Delivering a defined task with tests and an accurate status record.
  • Writing code a reviewer understands and revises with specific feedback.
  • Recording a debugging attempt, evidence, and an appropriate escalation.
  • Updating an estimate when scope or evidence changes.
  • Writing a pull request with context, checks, risk, and rollback.

Time in role does not establish readiness by itself. Opportunity, workload, mentorship, accommodations, leave, and employer process also affect advancement.

From Mid-Level to Senior

Senior criteria vary. Use the following categories only when they match the target employer’s framework.

Possible Technical Evidence

  • System design: design entire services or subsystems, including data model, API surface, failure modes, and scalability strategy.
  • Code review: write review comments that explain the why, not just flag problems. Make reviewees better, not just correct.
  • Production ownership: understand monitoring, alerting, on-call response, and postmortem process. Own the reliability of your systems.
  • Technical debt judgment: distinguish debt that must be paid now versus debt that is safe to carry. Make the argument to leadership when repayment is urgent.

Possible Collaboration Evidence

  • Scope ambiguity handling: given an ambiguous requirement, you write the spec, not wait for one.
  • Stakeholder communication: translate technical issues for product managers and business stakeholders.
  • Estimation at project scale: estimate multi-week or multi-month projects, not just individual tickets.
  • Mentoring: actively improve the skills of junior developers on your team through code review, pairing, and design review.

Common Traps That Stall Advancement

  • Using an undocumented standard. Ask for the written level criteria and review process.
  • Taking work without support. Define authority, time, access, review, and rollback first.
  • Recording no evidence. Save approved design notes, review feedback, test results, and outcomes within employer policy.
  • Treating disagreement as a level test. Use the team’s decision process and raise risk with evidence.
  • Taking unbounded work. Agree on authority, support, workload, credit, review, and compensation before accepting sustained next-level duties.

Accelerating the Timeline

Three actions support a measured growth plan:

  1. Set a mentoring agreement. Define goals, cadence, confidentiality, and an end date.
  2. Join operations only with safeguards. Require training, shadowing, pay, staffing, escalation, access limits, and recovery time before on-call work.
  3. Write a small design note. Include requirements, trade-offs, risks, rollback, and reviewer feedback.

Next Steps

Practice and Verify

Artifact: Growth evidence plan. Map current evidence across delivery, debugging, review, design, operations, mentoring, communication, and domain knowledge. Ask a manager or mentor for role-framework feedback. Choose one supported stretch task with owner, review, rollback, and workload boundaries.

Expected result: A dated matrix names evidence, gaps, support, and a review date without assuming a universal timeline.

REDACTED COMPLETED EXAMPLE
Gap: design trade-offs. Task: small design note. Reviewer: senior peer. Boundary: two hours weekly. Review: 30 days.

Pass checklist

  • The artifact uses dated, role-specific evidence
  • Claims, ownership, team credit, and unknown values are truthful
  • Privacy, secrets, licenses, accessibility, cost, and safety received review where relevant
  • A reviewer or repeatable check produced feedback
  • The record names a timed next action and checkpoint

Source rule: Use the employer’s role framework or a named public framework checked on the record date.