Engineering craft and career

Sections: 6
Pages: 166
Reading time: ~6 h
Take first: Nothing

What you will be able to do

Describe concretely what is expected at junior, SDE2, SDE3 and staff levels, and map your current work against it.
Write code, tests and pull requests that are easy to review and maintain, and give code reviews that improve both code and people.
Debug unfamiliar systems methodically and own your services in production.
Write a design doc, estimate and plan a multi-week project, and drive it to launch with clear status communication.
Work effectively with PMs, designers and other teams, including disagreeing productively.
Build a promotion case with evidence, and manage your career deliberately.
Prepare for and pass coding, system design and behavioral interviews, and negotiate the offer.

Technical depth gets you hired. Craft, ownership and communication decide whether you get trusted with bigger problems — and whether you get promoted. An SDE2 is someone the team trusts to own a feature end to end without hand-holding. An SDE3 is someone the org trusts to own ambiguous problems and raise the bar for the people around them. This topic is the operating manual for that climb: what each level actually means, how to write and review code others can live with, how to drive projects and collaborate, how promotions really work, and how to interview for the next role.

It sits next to the technical courses in this bible, not under them. You can design a cache and still ship unreviewable PRs. You can recite CAP and still drop the ball on a launch. The pages here are the habits and mental models that turn technical capability into reliable impact.

Who this is for

You are a junior or mid-level engineer aiming at SDE2, or an SDE2 starting to look like SDE3. You write code comfortably. You want concrete expectations — not vague advice to "take ownership" or "be more senior."

Take What the levels mean, Ramping up and Ownership early, even in your first months on a team. Return to craft, project ownership, people skills, promotions and interviewing as those situations appear. You do not need to read every page in order every year; you need the right page when the job changes shape.

If you are brand new to industry engineering, start with levels + ramp + ownership, then maintainable code, testing and code review. If you already ship features but stall on promotion, jump to scope growth, promotion and communication. If you are interviewing soon, use the Interviewing unit with a clock — strategy first, then coding and behavioral practice.

How to study it

Read against real work. After engineering levels, map one recent project onto the four axes (scope, autonomy, complexity, influence) and write what would have to be true for the next level. After code review, change how you open your next three PRs. After design docs, write a one-pager before your next non-trivial change.

Use the Further learning links when you need depth — public ladders, StaffEng essays, interview loops — not as a reading list to finish. Pair interviewing pages with timed practice; pair production-ownership pages with your next on-call shift.

Keep a short private "career log": projects, incidents, design reviews, mentoring moments, with outcomes and your role. That log feeds promotion packets and behavioral stories later; building it continuously costs minutes, rebuilding it from memory before a packet costs weeks.

Unit roadmap

The numbered list is a shorter path. The sections below are every lesson: 166 in all, about 6 hours of reading.

Levels and expectations

What "good" looks like at each stage, and how to get productive in a new environment.

What the levels mean — junior, SDE2, SDE3 and staff across scope, autonomy, complexity and influence
Ramping up on a new team and codebase — first 90 days: reading code, asking well, shipping early
Ownership — outcomes over tasks, closing loops, reliability as reputation

Craft of code

The daily work that builds trust in your diffs.

Writing code others can maintain — naming, deep modules, interfaces, consistency
Testing strategy — what to test, at which level, keeping suites fast
Code review — reviewable PRs and reviews that improve code and people
Debugging — systematic method from local repros to incidents
Refactoring and legacy code — characterization tests, small steps, migration
Working effectively with AI coding tools — speed without shipping code you do not understand

Owning projects

From idea to production without dropping the thread.

Design docs and RFCs — structure, alternatives, getting to a decision
Estimation and planning — ranges, risk, milestones
Driving projects to launch — kickoffs, status, dependencies, launch checklists
Working with product managers and designers — scope, trade-offs, building the right thing
Owning your code in production — on-call, alerts, runbooks, operational habits

Working with people

Influence, feedback and growth with other humans.

Written and verbal communication — updates, docs, Slack, executives
Collaboration and disagreement — influence without authority, disagree-and-commit
Mentorship: getting it and giving it — mentors, sponsors, mentoring as an SDE2
One-on-ones, feedback and performance reviews — managing up and navigating review cycles

Growing your career

Deliberate scope, promotions and sustainability.

Growing your scope — tasks → features → projects → problems
How promotion works — evidence, packets, calibration, manager conversations
Productivity, focus and sustainability — leverage, deep work, saying no
Career strategy — companies, teams, generalist vs specialist
The path to SDE3 and beyond — technical leadership, multiplying others, ambiguity

Interviewing

Getting the next role and the offer that matches it.

Interview preparation strategy — loop structure and a 6–10 week plan
Coding interviews — patterns, process, communication
Behavioral interviews — story banks, STAR, leveling
Offers and negotiation — packages and professional negotiation

Course resources

Gergely Orosz's The Software Engineer's Guidebook is the closest single book to these pages — levels, craft, collaboration and career moves in one place.

The Software Engineer's Guidebook (Gergely Orosz)Navigating senior, tech lead, staff and principal positions at tech companies and startups.The Software Engineer

Will Larson's StaffEng site and book are the canonical map of staff-level IC work and archetypes; read them when SDE3 starts to feel close.

StaffEng (Will Larson)Staff Engineer: Leadership beyond the management trackStaff Engineer: Leadership beyond the management track

Edmond Lau's Talks at Google session is the best short treatment of leverage — choosing work that compounds — which underlies ownership and productivity throughout these pages.

The Effective Engineer | Edmond Lau | Talks at GoogleTalks at Google

Public ladders beat tribal folklore. Bookmark Dropbox's Engineering Career Framework, the collection at progression.fyi, and levels.fyi for cross-company title mapping when you change jobs or negotiate.

Levels and expectations

The four leveling axes

Scope, autonomy, technical complexity and influence — the four questions every engineering ladder is really asking.

What the levels mean

Junior, SDE2, SDE3 and staff: scope, autonomy, impact and influence at each level.

Junior and SDE2

Juniors finish well-scoped work cleanly. SDE2s own features end to end without someone breaking the work into steps.

Senior and staff

Senior owns ambiguous multi-quarter problems and multiplies the team. Staff is a different job shape, not a louder senior.

Mapping titles across companies

Senior at a startup may be mid-level at big tech. Map with scope, autonomy, complexity and influence — not vanity strings.

Leveling self-assessment

Pick a public ladder, score three recent pieces of work on the four axes, and mark what you show consistently versus once.

The first 90 days

Agree 30/60/90 outcomes with your manager so ramp is visible, not a vibe.

Reading an unfamiliar codebase

Trace one request from an entry point. Tests and git history beat reading src/ top to bottom.

Asking good questions

Show what you tried, time-box being stuck, and batch questions so help is cheap to give.

Ship something small in week one

A tiny production change teaches the real workflow. A tutorial app on your laptop teaches none of it.

Ramping up on a new team and codebase

Your first 90 days: read code by tracing paths, ask well, ship early, and map people as well as systems.

Closing loops

Stay with the outcome, not the ticket. Every commitment ends done, cancelled, or deferred with an owner and a date.

Reliability as reputation

Do what you said, by when you said, or renegotiate before the deadline. Quiet misses train people to discount you.

Done means verified

Tests, monitoring, a rollback path, and a check in production are part of done — not polish if there is time.

Proactive ownership

Find problems before they are tickets, package them in risk language, and make yourself replaceable on purpose.

Ownership

Acting like an owner: close loops, care about outcomes, and be the person things do not fall through with.

Craft of code

Software complexity

Complexity shows up as change amplification, cognitive load and unknown unknowns. The next stranger's change is the cost that matters.

Deep modules

A deep module hides a lot of complexity behind a small interface. Shallow pass-through layers add names without adding leverage.

Writing code others can maintain

Managing complexity with deep modules, clear naming, honest comments, consistent style, and error strategies that shrink the blast radius of change.

Naming and comments

Names encode role and units. Functions do one thing at one level. Comments explain why, not what.

Error handling and illegal states

Fail fast, make errors explicit, and redesign so some failures cannot happen. Swallowing errors turns production into archaeology.

Duplication vs the wrong abstraction

DRY is about knowledge, not text. Prefer duplication over a shared helper you cannot name. YAGNI for imaginary second use cases.

Interfaces that age well

Design the interface for the caller's job. Take the smallest inputs, make illegal states hard, and keep one obvious way to do each thing.

Test levels

Unit, integration, contract, and end-to-end tests buy different confidence per minute. Pick with cost, not habit.

Test doubles

A stub returns canned data. A fake is a small working stand-in. A mock also checks how it was called. Prefer fakes and real dependencies.

Testing behavior

Assert inputs and outputs the next engineer cares about. Do not lock tests to private call graphs, logs, or getters.

Testing strategy

What to test, at which level, and how to keep a suite fast, reliable, and worth the maintenance — from pyramid trade-offs to production safety nets.

Flaky test policy

A flake fails without a code change and trains the team to ignore red CI. Quarantine it the same day; fix or delete it within days.

Testing in production

Pre-prod tests never see every config, data shape, or traffic pattern. Flags, canaries, and synthetics catch what the suite cannot invent.

Reviewable pull requests

Small diffs, a stranger-readable description, and a self-review before you ask anyone else.

What to look at in a review

Design, then correctness, then tests, then readability, then nits. LGTM means you would own the merge.

Review tone

Questions and labeled nits beat commands. Explain why. Specific praise teaches what to repeat.

Code review

Author small, reviewable PRs and give reviews that improve both the code and the author — design first, tone that teaches, turnaround that unblocks.

Review turnaround

Slow review is a delivery bug. First response within a business day; silence is worse than a redirect.

Block vs approve

Block what is wrong, unsafe or expensive to undo. Approve improvements and track leftover polish.

Ops and security in review

Authz, secrets, PII, migrations, flags and load. You do not need to be a security engineer to ask who can call this.

The scientific debugging loop

Observe a concrete failure, form a killable hypothesis, change one variable, narrow, repeat. Write it down.

Reproduce and minimize

The smallest steps, inputs and environment that make the bug happen reliably. Without a repro you are guessing.

Bisecting bugs

Binary search the search space — code path, commits, input, config, cluster. git bisect is log2(N) builds.

Debugging

A scientific loop for finding bugs fast — reproduce, hypothesize, bisect, instrument — from local failures to production incidents without making things worse.

Reading debug evidence

Stacks, logs, metrics and traces. The exception escaped somewhere; the mistake may be a frame earlier.

Production debugging

Correlate, stabilize, capture evidence. Do not thrash. Separate mitigation from the root-cause fix.

Closing the debug loop

A fix without a regression test is temporary. Write what you saw, what was true, and how it cannot silently return.

Characterization tests

Pin what legacy code does today before you clean it, so a refactor cannot drift in silence.

Seams and dependency breaking

A seam is a place you can change behavior without editing the hard spot. Create one before you rewrite the algorithm.

Tiny refactor steps

One structural change, tests green, commit. Then change behavior in a different PR.

Refactoring and legacy code

Change code you did not write without breaking it. Start here for characterization, seams, tiny steps, and incremental migrations.

Incremental migrations

Replace a system the way a strangler fig replaces a host — route by route, with expand/contract and parallel run, never a six-month freeze.

Selling tech debt

Fund cleanup with incident rate, speed, and risk — not "this code is messy" — and show progress on a dashboard.

AI coding modes

Autocomplete completes patterns you already understand. Chat drafts and explains. Agents edit many files against a pass/fail signal.

Agent verify loops

An agent only helps when it can fail a test, a typecheck, or a repro script. You define done. You still review the merge.

Working effectively with AI coding tools

Use autocomplete, chat, and coding agents to go faster without shipping code you do not understand — context, verify loops, and protecting your skill growth.

Prompting AI coding tools

Load a goal, an example, constraints, and non-goals. Point at the files that matter. Keep project instruction files short and true.

Reviewing AI-generated code

Review AI output with the rigor of a new-hire PR. Characteristic failures are invented APIs, skipped auth, and tests that assert mocks.

Learning with AI tools

Seniors multiply with AI. Juniors risk never building the mental models that make them SDE2. Protect growth on purpose.

Owning projects

When to write a design doc

Skip the doc for small reversible work. Write one when the blast radius is large, the approach is unclear, or you need buy-in.

Design docs and RFCs

Writing design docs that get to a good decision quickly — structure, alternatives, review, and when a one-pager is enough.

Design doc template

Context, goals and non-goals, the proposed design, real alternatives, then risks and rollout. Cut empty sections.

Writing design docs for reviewers

Lead with the decision on the first screen. Support it with diagrams and numbers. Ask for scrutiny, not applause.

Running a design review

Pick reviewers on purpose, go async first, meet only for stuck threads, and record the decision so code review does not re-litigate it.

Estimate vs commitment

An estimate is a range under uncertainty. A commitment is a date you agree to hit, usually by cutting scope. Do not give one when asked for the other.

Work breakdown and spikes

Split work until each leaf is about one or two focused days. Time-box unknowns as spikes before you pretend to know their cost.

Estimation and planning

Breaking work into small tasks, estimating with ranges, de-risking early, and communicating slips before they become surprises.

Estimate ranges and padding

Quote a range and a confidence, then multiply the raw sum out loud for unfamiliarity. Hidden padding is how trust dies.

De-risking and milestones

Pull the scary integration forward, then ship user-value slices. Easy UI first feels like progress and hides the landmine.

Evidence-based scheduling

Track estimate versus actual on small tasks, then multiply new work by your personal factor instead of summing hopeful guesses.

Communicating slips

Say the assumptions with the number. When they break, renegotiate early with options — cut scope, move the date, or (rarely) add people.

DRI and kickoff

One named owner, a short kickoff, and a definition of shipped that is more than code on main.

Green, yellow, red status

Status is a forecast of launch, not a diary of tasks. Yellow on Tuesday beats red the day before.

Dependencies and unblocking

Other teams will not feel your deadline. Ticket, follow up, escalate with options — and parallelize while you wait.

Launch readiness

Merged to main is not launched. Walk monitoring, rollout, rollback, docs, and a named owner before the flag goes to 100%.

Driving projects to launch

Kickoffs, status, dependencies, unblocking, launch checklists, and a finish decision-makers recognize as shipped.

Discovery and delivery

Discovery figures out what to build. Delivery builds and ships it. Engineers belong in both, as peers of PM and design — not a ticket factory.

Cheaper product cuts

Start from the user problem and success metric, then offer an MVP with a cost and a risk — not a yes or a no.

Working with product managers and designers

Product sense for engineers — shaping scope, trade-off conversations, feasibility spikes, and building the right thing with PMs and designers.

Feasibility spikes

Surface a hard constraint before design is locked. Time-box a spike and come back with a recommendation and residual risk.

Working with designers

Designers are partners on empty, error, and permission states — not pixel people you implement after the fact.

Product-minded habits

Curiosity about the user, interest in metrics, and ownership after launch — not a PM title.

Shipping with observability

A feature is not done when the happy path works locally. Done means someone half-asleep can tell whether it is healthy.

Handling a page

Acknowledge, assess blast radius, mitigate first, escalate when needed, communicate. Diagnose after users are safe.

Runbooks and toil

Write the checklist you wish existed at 2 a.m., then spend the next days making that page never happen the same way.

Owning your code in production

On-call, alerts, runbooks, and the loop that makes you trustworthy — and better at building systems that survive users.

Production postmortems

Blameless writeups so the system learns. Your job is timeline facts, contributing factors, and action items you actually finish.

Working with people

Bottom line up front

Put the decision, ask or outcome in the first sentence. Context comes after.

Writing for skimmers

Assume a tired reader on a phone. Headings that say something, one idea per paragraph, links instead of dumps.

Status and decision updates

Shared templates for status, incidents and decision requests so readers know where to look.

Async etiquette

Chat is a shared inbox. Put the full ask in message one, use threads, and match the medium to the urgency.

Written and verbal communication

Lead with the point, write for skimmers, and adjust depth for engineers, PMs and executives.

Audience altitude

Same facts, different height. Mechanism for engineers, impact for PMs, decision and ask for executives.

Meetings and demos

Open with the purpose, show the user path, and leave with a decision, an owner and a date.

Building trust before you need it

Trust is credit you earn in quiet weeks. Keep small commitments, share context early, make others look accurate.

Disagreeing well

Critique the proposal, not the person. Bring facts, options and a recommendation, then disagree-and-commit.

Influence without authority

Shrink the ask, do their first draft, name shared upside, and escalate with options rather than a complaint.

Collaboration and disagreement

Build trust before you need it, disagree with data and options, and make cross-team asks easy to grant.

Cross-team asks

Other teams have roadmaps and review queues. Make saying yes the path of least resistance.

Glue work

The connective tissue that lands projects — and stalls careers if it leaves no artifact. Do it, name it, time-box it.

Psychological safety

People can ask a dumb question, admit a miss, or challenge a plan without being punished. That is not low standards.

Mentors, coaches and sponsors

Mentors advise, coaches question, sponsors put reputation on the line. You need a mix, not one perfect person.

Mentorship: getting it and giving it

Distinguish mentors, coaches and sponsors — then ask well, mentor juniors and grow others as an SDE2.

Asking for mentorship

Ask with a bounded cadence, an agenda and a specific question tied to an artifact. Vague "be my mentor" contracts get declined.

Mentoring juniors

Onboard with a first-week win, teach through reviews, and coach with hints unless the cost of delay is a sev.

Building a mentor bench

Several partial relationships beat one oversubscribed senior. Split craft, career, domain and peer. Cap how many people you mentor deeply.

Sponsorship and growing others

Promotion committees look for people you raised, not Slack answers. Track mentee outcomes the way you track projects.

Running your 1:1s

A 1:1 is not a status meeting. Bring an agenda, rotate themes, and write down the decisions.

Asking and receiving feedback

Specific prompts soon after the work beat "any feedback?" Receive by summarizing first. Evaluate truth later.

Giving feedback with SBI

Situation, Behavior, Impact. Observable events, not character. Praise in public when it will not embarrass; correct in private.

Brag documents

A living note of what you did, the impact, links, and kudos. Review cycle you then compile, not invent.

One-on-ones, feedback and performance reviews

Run your 1:1s, ask for and act on feedback, and keep a brag document through review cycles.

Performance review cycles

Self-review, peers, calibration. Make the true story easy to find, and never let a serious concern appear for the first time on the form.

Growing your career

The scope ladder

Titles track the size of problem you can be trusted with — task, feature, project, then a multi-team problem.

High-leverage work

Impact per hour hides in on-call themes, stuck metrics, roadmap gaps, and daily team friction — not in tickets labeled "promo project."

Growing your scope

From tasks to features to projects to problems: finding and taking on higher-leverage work.

Volunteering for scope

Finish before you expand. Volunteer for the gap your next level requires, with an explicit metric, time box, and non-goals.

Making impact visible

Calibration cannot see work you never wrote down, measured, or demoed. Leave artifacts on purpose.

Promotion is lagging recognition

You get the title after you have already been operating at the next level, usually for more than one cycle.

Building a promo packet

Map two or three linked examples to each next-level criterion. Cut anything that only proves your current level.

Working with your manager on promo

Make the goal explicit, share the brag doc early, and ask for scope that fills gaps — not only adjectives.

How promotion works

Evidence, packets, calibration and the manager conversations that turn next-level work into a title.

Promo blockers and when to move

Most stuck cases are missing scope, invisible impact, or a team with no next-level problems. Sometimes leaving is the plan.

Engineering leverage

Impact divided by time. Ask what the next hour is worth, not whether you looked busy.

Protecting focus time

Hard engineering needs uninterrupted stretches. Treat focus blocks like meetings with a critical stakeholder — you.

Tooling and automation

Time spent learning your editor, shell, and a boring automation threshold compounds for years.

Saying no

Every yes is a no to something else. Seniors allocate help on purpose, with timed yes, partial yes, or an explicit tradeoff.

Productivity, focus and sustainability

Leverage, deep work, saying no, and a pace you can still think clearly at in year five.

Sustainable pace

Burnout is a prolonged mismatch between demand and recovery. Treat the warning signs like a production alert.

Company stage

Big tech, growth-stage and early startup trade learning, scope, pay and risk. Pick the trade for this season.

Choosing teams

Over a two-year window, manager plus business importance plus technical growth usually beats the company logo.

T-shaped skills

Depth in one stem the market pays for, plus a crossbar of literacy so you can collaborate and switch.

Career strategy

Choosing companies, teams and specialties deliberately: big tech vs startups, generalist vs specialist.

Evaluating startup offers

Separate cash, equity, runway and scope. A large option grant is a probability distribution, not a salary.

When to switch jobs

Switch when growth is structurally blocked. Stay when a scope jump or rare exposure is coming. Leave with reputation intact.

A light public profile

Discoverability and proof, not an influencer side hustle. Short posts, one talk, small PRs, factual LinkedIn.

Owning ambiguity

Senior work starts when the problem statement is incomplete. You write down the goals, constraints, and success metrics for others.

Technical leadership without management

You do not need reports to lead. Use design reviews, standards, short strategy, and reviews that teach — and keep coding enough to stay credible.

The path to SDE3 and beyond

What senior engineers do differently: technical leadership, multiplying others and owning ambiguity.

Navigating organizations

Technical excellence that ignores organizations dies in a ditch. Alignment is getting the right people to agree, then keeping that agreement alive.

Staff archetypes

Tech lead, architect, solver, right hand — and the IC vs manager fork. Pick a game on purpose. Do not become a manager because promo is blocked.

A plan from SDE2 to SDE3

A 12–24 month template with explicit gaps, one senior-shaped project, wider influence, and anti-patterns that feel like progress.