Five levels, eight skills, and a receipt for each one.
Every step from junior to senior is tied to something real: a change you shipped, a review you took, a call you stood by. Nothing about your level is decided on a feeling, and the record leaves with you.
Level 1 is the day you start.
Level 5 is a certificate you can take into a senior interview and back up with real work. Between them is the climb, a level at a time, with the team alongside.
- .01Onboarded
L1. Onboarded. You've got the basics. You can ship simple work with guidance.
Your first weeks. You pick up small tasks, learn the codebase, and start opening code changes the team can review. Nobody expects you to know everything yet.
- .02Junior
L2. Junior. You work mostly on your own. The team still reviews you closely.
You can take a small feature from a task to a finished, shipped change. You ask better questions, write tests without being asked, and start catching your own bugs before the team does.
- .03Mid-level
L3. Mid-level. You own features end-to-end. You review other people’s code.
You take a problem, design the solution, ship it with the right tracking, and watch it once it’s live. You leave reviews that catch design issues, not just style. The team trusts your judgment on small calls.
- .04Senior
L4. Senior. You own systems. You make calls across teams.
You design across team boundaries. You spot what's going to break before it happens. You make the trade-offs explicit, and other engineers build against the direction you set.
- .05Senior verified
L5. Senior verified. The record proves it. You can interview senior and pass.
Eight skills, each backed by evidence in your real GitHub history. A senior team that watched you do the work signs off. The certificate is yours to keep, and anyone can check it.
What you are being judged on.
Nobody expects all eight on day one. You grow them at your own pace, and each one is only ever marked from something you actually did.
Technical Depth
You don’t just patch bugs. You find why they happened. You read the actual code over the docs, and you know the systems you touch from end to end.
Marked from: A write-up explaining the real cause of a bug. A debug session that went deeper than the team expected.System Design
Before writing code, you think about how the pieces fit, where they could break, and what the trade-offs are.
Marked from: A design doc with alternatives weighed. A change description that explains how things connect, not just what changed.Production Sense
Your code doesn’t just work on your machine. It works at scale, under load, and when something goes wrong, because you thought about that part too.
Marked from: Tracking added before the change ships. A plan for how to roll it back. A real incident you actually thought through.Judgment
When the plan isn’t clear, you make a good call and explain why. You name the unknowns instead of pretending they aren’t there.
Marked from: A written decision on a task with no clear answer. A call you stood by under pushback.Ownership
If something needs fixing, you don’t wait to be asked. You see it through to shipped, watched, and stable, not shipped-and-gone.
Marked from: A follow-up after shipping. A bug you raised that nobody asked you to look at.Communication
You write so people understand the first time. Your code changes answer the why, not just the what.
Marked from: A change description a reader could understand with no extra context. A summary that got everyone aligned in one read.Code Review
You raise the bar on other people’s work without slowing them down. You catch the real issues, explain your reasoning, and approve cleanly when it’s ready.
Marked from: A review comment that caught a design issue. A teammate’s change that came back stronger.Mentorship
You make the people around you better. You explain instead of just fixing. You work side-by-side with others willingly and name their work in rooms they aren’t in.
Marked from: A work-along session that taught something. A review that explained the principle, not just the change.How the team watches.
Every observation is tied to something specific you did, and you can read every one of them.
- 01
You ship the work.
A change opened, a review left, a plan defended, a call made. The team is in the room for every one of them.
- 02
The team writes it down.
A teammate logs a short note: what you did, which skill it touched, and a link to the evidence.
- 03
The record adds up.
Over weeks the notes accumulate. You can see where you are strong and what is still ahead, at any time.
- 04
You move up when you are ready.
When the record clears the bar the team signs off. When it does not, they tell you what is missing, specifically.
The record is yours, and it keeps.
Your changes stay on GitHub. The notes stay against your level. The certificate at L5 is something a hiring manager can read and verify long after you have finished here.