Sefism Mid-level to Senior Cheat Sheet

What this cheat sheet is

The Sefism Mid-level to senior cheat sheet is a reference for engineers working towards a senior role, and for new seniors who want to do the job well. It collects the ideas and vocabulary behind seniority in one place: what scope means, how ownership and leverage work, how design writing turns debates into decisions, how to multiply the people around you, how to stay visible without playing politics, and how influence works when you have no authority.

It has six chapters and 47 concepts. Each concept gives what it is in plain words and why it matters, and most add a concrete example and the mistake people usually make. Two concepts carry a ready-to-copy outline: the sections of a design doc (context, goals and non-goals, proposed design, alternatives, risks and cost, rollout, open questions) and a short sample architecture decision record. Around them sit eight rules of thumb and a glossary of the smaller terms used in level frameworks and promotion discussions.

Who it suits

Mid-level engineers who keep hearing "more impact" or "more ownership" and want the words made concrete, seniors preparing for a promotion conversation or a self-review, and anyone reading their company's career ladder and wondering what "operates with ambiguity" looks like in practice. If you are in your first year, the Your first tech job cheat sheet is a better starting point; if you are already looking at staff or management roles, see the Staff and leadership cheat sheet.

Chapter by chapter

1. Seniority as scope, with a clear bar

Seniority as the ambiguity and responsibility you handle without being told what to do. Concepts: scope (from a task to several teams), handling ambiguity (turning "checkout feels slow" into goals, questions and a plan), impact over output, level framework, the gap to the next level, written expectations, monthly progress check-ins, and performing at the next level, the common rule that you are promoted after consistently doing next-level work for a period.

2. Ownership and leverage

More tickets and longer hours have a ceiling. Concepts: ownership (including the parts nobody assigned, such as rollout, monitoring and follow-ups), leverage as impact per hour, unowned problems, root cause over workaround, prioritisation and saying no, automation and internal tooling, measuring before and after, and simplicity.

3. Own the design: write to decide

Writing options, trade-offs and a recommendation so an argument becomes a decision. Concepts: design doc, goals and non-goals, trade-off analysis, architecture decision record, design review, one-way and two-way doors, design principles as shared vocabulary (separation of concerns, SOLID, KISS, DRY, YAGNI), and estimates as ranges, such as "3 to 5 weeks, depending on the payments API".

4. Multiply the people around you

Your own output has a ceiling; your team's does not. Concepts: force multiplier, code reviews that teach (explaining the reasoning, separating blocking issues from suggestions), coding standards enforced by formatters and linters, mentoring, pairing and unblocking, direct and kind feedback, and documentation such as runbooks and onboarding guides.

5. Visibility without politics

Good work that leaves no trace is invisible at review time. Concepts: brag document, regular updates to your manager, self-review, promotion packet, calibration (how managers compare cases across teams), peer feedback, writing up incidents and outcomes, sponsor (someone who uses their influence for you, unlike a mentor who advises), and sharing work beyond your team.

6. Influence and choosing your direction

Getting things done without authority, and choosing where to go next. Concepts: influence without authority, talking one to one first, building trust across teams, disagree and commit, deep, broad or leadership, IC and manager tracks, and knowing when to move on.

Each chapter points to up to three library resources for depth, such as Engineering Ladders, Software Engineering at Google, Kind Engineering, Get Your Work Recognized: Write a Brag Document and StaffEng.

The rules of thumb

Eight one-line rules close the sheet, including: ask for the next level's expectations in writing and review progress monthly; look for pain everyone complains about and nobody owns, then fix the root cause visibly; write before you build anything that takes more than a couple of weeks; measure the baseline before you change something; update your brag document every Friday in five minutes; explain the why in every review comment that asks for a change; and do the work of the next level before expecting the title.

How to use it with the roadmap

The six chapters match the six stages of the Mid-level to senior roadmap, and the roadmap's topics link to the concepts that cover them.

• Revise after each stage, and check you can explain each concept with an example from your own work.
• Before writing a design doc, copy the outline from chapter 3 and reread trade-off analysis and one-way and two-way doors.
• Before a one-on-one about promotion, reread chapters 1 and 5 so you can talk in your company's terms: scope, written expectations, calibration, packet.
• At self-review time, use chapter 5 to turn your brag document into evidence against each expectation.
• Before a senior-level interview loop, use the vocabulary to describe your own projects precisely: what you owned, what you measured, what you decided and why.

How it works on Sefism

Everything on Sefism is free to learn from. The public page at /cheatsheets/career-growth/ lists every chapter title, with the first chapters open to read. Keeping the sheet uses a few credits, and new members get starting credits; following the Mid-level to senior roadmap also unlocks it. Once it is yours, every chapter opens in the member area, searchable by the names people actually use, such as "career ladder" or "promo case". Create a free account to start, or ask Tauseef a question about your own situation.

Related on Sefism

• Mid-level to senior roadmap, the companion learning path
• SDE 1 vs SDE 2
• How to ask for a raise as a software engineer
• How to become an engineer your team trusts
• What to do when you disagree with a senior engineer
• Twelve moves that take you from mid level to senior
• Path to Senior Engineer Handbook in the library

FAQ

What is the difference between a mentor and a sponsor? A mentor advises you. A sponsor uses their influence for you: recommending you for important work, mentioning you in rooms you are not in and backing your promotion.

What is calibration? A meeting where managers compare ratings and promotion cases across teams so the same standard is applied to everyone. It is why written evidence matters more than your manager's memory.

What goes in a brag document? What you did, why it mattered, and evidence such as numbers, links and thanks from others, added weekly while the details are fresh.

What is an ADR? An architecture decision record: a short file, often kept in the repository, recording one decision with its context, status and consequences.