Software Engineer
From first program to staff engineer: the whole career, in order, on free resources.
- Lessons
- 98 lessons
- Time
- Job-ready in about 10 months at 10 h a week
- Creators
- 52 creators on YouTube
- Learners saving progress
- 1 learners
Curated by SageLords
Explorer to Expert
13 stages. Job-ready in about 10 months. The track keeps going for 2 levels past the hire line, learned alongside your job, so they aren't counted.
Levels describe what you can do in this career. They aren't job titles and don't match any company's levels.
Who it's for
For career changers, self-taught developers and CS students who want a single ordered path into software engineering, and for working junior and mid-level engineers who want to know what the senior and staff skills actually are and how to practise them. You need about ten hours a week and a computer you can install software on. You do not need a degree or advanced maths. Not for you if you want to specialise deeply from day one (the Frontend, Backend and DevOps roadmaps go deeper on their layers), or if you want a job in three months. The path to a hireable level is roughly ten months at ten hours a week. The later phases assume you are working as an engineer: they take months of study and practice spread over years of real experience, and no course can shortcut that part.
Where this takes you
By the hire line you can take a written spec, design the data model and API, build the interface, add authentication, test it, ship it through CI to a real URL, and defend your decisions out loud. You hold a deployed portfolio application with a spec, ADRs and tests, and a merged open-source contribution. By the end you can design systems and defend the trade-offs, own a service in production with SLOs, alerts and runbooks, write design documents and ADRs that get significant changes agreed, lead incidents and blameless postmortems, mentor engineers, set the standard for code review, and write technical strategy that aligns several teams. The evidence is an architecture review, an operations pack, a reviewed design document, a leadership record and a staff-level impact portfolio, each judged against a stated rubric.
Syllabus
Every lesson is open. The order is a recommendation, not a lock.
Explorer, three levels below the hire line
1 stage · about 6 hours
1
Orientation
You can decide, with real information rather than hype, whether you want to spend the next year or more becoming a software engineer.
Learn6 lessons · about 6 hours- 1
What software engineers actually do all dayForrestKnightStart here - 2
The career ladder: junior, mid, senior, staffJohn Kim - 3
The junior market in 2026, honestlytheSeniorDev - 4
How to learn this without drowning in tutorialsWeb Dev Simplified - 5
Set up your machine and get comfortable in a terminalTraversy Media - 6Milestone: decide to continue or stop
- 1
Novice, two levels below the hire line
1 stage · about 8 weeks
2
Foundations: programming and problem solving
You can turn a small, clearly stated problem into a working JavaScript program, explain how it works, and say roughly how its running time grows with its input.
Learn9 lessons · about 8 weeksGuided build- 7
How computers represent data and run programsCS50 - 8
JavaScript fundamentals: values, control flow and functionsfreeCodeCamp.org - 9
Problem solving: breaking a problem down before writing codeFireship - 10
Core data structures: arrays, hash maps, sets, stacks and queuesSajjaad Khader - 11
Big-O: reasoning about how code scalesNeetCode - 12
Recursion and thinking in smaller subproblemsReducible - 13
Git and GitHub for your own workfreeCodeCamp.org - 14
How the web works: HTTP, DNS and the request-response cycleTraversy Media - 15Reading documentation, searching errors and asking good questionsJulia Evans
Prove it: Guided build
A public GitHub repository containing at least 40 solved exercises (Exercism's JavaScript track, CS50 problem sets or equivalent), committed as you go, plus a short NOTES.md. It is good when: each solution has a one-line comment explaining the approach in your own words; at least five solutions have a note on their time complexity; at least three were rewritten after you found a cleaner approach, with both versions in the history; and the commit history shows steady work over weeks rather than one bulk upload. This is follow-along-level evidence. It shows you can program; it is not portfolio material and you should not present it as such.
- 7
Advanced beginner, one level below the hire line
2 stages · about 4 months
3
Core skills: building for the web
You can build a small web application with a React interface, a Node.js API and a PostgreSQL database by following documentation rather than a tutorial.
Learn10 lessons · about 3 monthsGuided build- 16
HTML and CSS: semantic structure and modern layoutfreeCodeCamp.org - 17
The DOM and events without a frameworkfreeCodeCamp.org - 18
Asynchronous JavaScript, promises and the event loopfreeCodeCamp.org - 19
TypeScript: types as documentation and a safety netfreeCodeCamp.org - 20
React: components, props, state and effectsJavaScript Mastery - 21
Building an HTTP API with Node.js and ExpressfreeCodeCamp.org - 22
Designing REST APIs other people can useHayk Simonyan - 23
SQL and PostgreSQLfreeCodeCamp.org - 24
Designing a relational schemaDecomplexify - 25
Talking to Postgres from code: an ORM and migrationsPedroTech
Prove it: Guided build
Three small working apps in your GitHub, each extended beyond the tutorial you learned from: a React interface that fetches from a public API, an Express API with at least four endpoints, and a Postgres-backed version of that API with a schema you designed. It is good when each repository has a README that says what you added beyond the tutorial, the API returns correct status codes for missing and invalid input, and you can draw the schema from memory. This is still guided work and should be described honestly as practice.
- 16
4
First build
You can build and deploy a small full-stack application from a written specification without following a tutorial.
Build6 lessons · about 5 weeksIndependent project- 26Turning a spec into small tasks you can finishAtlassian
- 27Configuration, environment variables and secretsAdam Wiggins
- 28
Debugging systematically instead of guessingWeb Dev Simplified - 29Deploying an application and its databaseRender
- 30Project: a reading-list application from a specExpress
- 31Milestone: ship it and get one piece of feedback
Prove it: Independent project
A deployed reading-list application built from the spec in this phase, at a public URL, with source on GitHub. It is good when: a stranger can use it without instructions; data survives a refresh and a redeploy because it lives in Postgres; invalid input gets a clear message and a 400 from the API, not a crash; a failed request shows an error state rather than a blank screen; there are at least fifteen commits whose messages explain why; secrets are not in the repository; and the README lets someone run it locally in five commands or fewer. It is not good if you cannot explain every file in it.
Job-ready after this level
Competent, the hire line
2 stages · about 3 months
5
Professional practice
You can deliver a change to an existing codebase the way a professional team expects: tested, reviewed, secure, readable and shipped through CI.
Practice10 lessons · about 6 weeksIndependent project- 32
Automated testing: unit and integration testsProgramming with Mosh - 33
End-to-end testing with PlaywrightfreeCodeCamp.org - 34
Working in a shared repository: branches and pull requestsTechWorld with Nana - 35
Giving and receiving code reviewMatt Stauffer - 36
Readable code: naming, structure and refactoringCodeAesthetic - 37
Authentication and authorizationPedroTech - 38
The security every web engineer is expected to knowAikido Security - 39
Error handling and loggingBetter Stack - 40
Continuous integration with GitHub ActionsGitHub - 41
Working from tickets in a team processCodex Community
Prove it: Independent project
Your first-build project upgraded to professional standard, with the upgrade visible in its history, plus one merged pull request to someone else's open-source repository. It is good when: there are unit tests for the core logic and at least three end-to-end tests for the main flows, and they run in GitHub Actions on every pull request; every change after this point arrived through a pull request with a description that says what and why; authentication is in place and a user cannot read or change another user's data (you have a test proving it); errors are logged with enough context to debug and users see a helpful message; and the open-source pull request was reviewed and merged by a maintainer. A reviewer should be able to open any pull request and understand the change without asking you.
- 32
6
Portfolio piece
You can design, build, ship and defend an application of your own that a hiring manager would accept as evidence you can do the job.
Build4 lessons · about 8 weeksPortfolio piece- 42Specifying and scoping your own projectJoel Parker Henderson
- 43Project: build and ship your portfolio applicationAdam Wiggins
- 44
The README, and defending your decisions out loudNextWork - 45Milestone: cross the hire line
Prove it: Portfolio piece
A deployed application of your own design, with a public repository containing a one-page spec, at least two architecture decision records, tests running in CI, and a README with screenshots, a live link and a 'decisions and trade-offs' section. It is good when: a reviewer can tell from the spec what problem it solves and for whom; the ADRs record real alternatives you rejected and why; authorization is tested; there are no secrets in history; the app handles errors and empty states gracefully; and in a ten-minute conversation you can explain any part of it, what you would change with more time, and what would break first at a hundred times the users. It is not good if it is a tutorial project with a new colour scheme.
Landing the job
2 stages · about 6 weeks
7
Interview prep
You can perform credibly in each round of a typical software engineering interview loop: coding, take-home, light system design and behavioural.
Career7 lessons · about 4 weeks- 46
What the interview loop looks likeFireship - 47
The coding round: patterns, not memorisationfreeCodeCamp.org - 48
Take-home assignments done properlyBrian Jenney - 49
Light system design for junior interviewsfreeCodeCamp.org - 50
The behavioural round and telling your storyMatt Huang - 51
AI assistants: the 2026 expectationForrestKnight - 52Mock interviews and rehearsalPramp / Exponent
- 46
8
Get hired
You can run a focused job search that produces interviews, and start your first role in a way that builds trust quickly.
Career5 lessons · about 2 weeks
Proficient, one level above the hire line
3 stages · learned alongside your job
9
System design and architecture
You can design a system for stated requirements, estimate its load, choose where state lives and how components communicate, and defend the trade-offs against the alternatives.
Learn10 lessons · about 6 weeksProduction ownership- 58
Managing complexity: deep modules and information hidingTalks at Google - 59
Design patterns, and when not to use themFireship - 60
Scaling fundamentals: load balancing, statelessness and cachingfreeCodeCamp.org - 61
Back-of-the-envelope estimationByteByteGo - 62
Data at scale: replication, partitioning and choosing a storeHayk Simonyan - 63
Asynchronous communication: queues and eventsHello Interview - 64Distributed systems fundamentals: consistency, consensus and failureMartin Kleppmann
- 65
Monoliths, modular monoliths and microservicesGOTO Conferences - 66
Communicating architecture with diagramsAgile on the Beach - 67
Practising system design end to endHello Interview
Prove it: Production ownership
An architecture review of a real system you work on (or a substantial open-source system if you have none): C4 context and container diagrams, a description of where each piece of state lives and who writes it, a back-of-the-envelope load estimate with your assumptions stated, the three most likely bottlenecks or failure points in priority order, and one proposed change with at least two alternatives considered. It is good when: a colleague who knows the system agrees the diagrams are accurate; the estimates are within an order of magnitude of real metrics where those exist; the priorities are justified by impact rather than by what is interesting; and the proposed change says what it costs, not just what it gains. It is not good if it describes an idealised system rather than the one that actually runs.
- 58
10
Running production: reliability, observability, performance and security
You can own a production service: deploy it safely, know when it is unhealthy before users tell you, find and fix performance problems, and keep it secure.
Practice8 lessons · about 6 weeksProduction ownership- 68
Containers for application engineersBetter Stack - 69
Safe deployments: rolling, blue-green, canary and feature flagsByteByteGo - 70
Observability: logs, metrics and tracesSystem Design Lab - 71
Service level objectives and error budgetsTech Tutorials with Piyush - 72
Being on call and responding to incidentsGoogle SRE Prodcast - 73
Resilience: timeouts, retries, idempotency and circuit breakersAlex Hyett - 74
Finding and fixing performance problemsGOTO Conferences - 75
Security in production: threat modelling and the supply chainNetsec Explained
Prove it: Production ownership
An operations pack for a service you own and that real people use, covering at least two months of operation: SLOs with their SLIs and the reasoning behind the targets; a dashboard and alerts tied to those SLOs; a runbook for the three most likely failures; one performance investigation written up with before-and-after measurements; and a threat model for the service. It is good when: alerts fire on user-visible symptoms rather than causes, and none fired falsely more than once without being tuned; a teammate can follow the runbook without you; the performance write-up names the bottleneck with evidence (a profile, a query plan, a trace), not a guess; and the threat model has led to at least one concrete fix. It is not good if the service has no real users or the dashboards have never been looked at during an incident.
- 68
11
Design docs, RFCs and ADRs
You can write a design document that gets a significant change reviewed and agreed, record decisions as ADRs, and present a technical proposal to a mixed audience.
Practice8 lessons · about 4 weeksProduction ownership- 76Why design docs exist and when to write oneMalte Ubl
- 77Clear technical writingGoogle
- 78
The anatomy of a good design docRomanticize Code - 79
Architecture decision recordsCodeOpinion - 80
RFCs and running a design reviewCracking FAANG - 81
Estimation and planning under uncertaintyModern Software Engineering - 82
Presenting technical ideas to a mixed audienceMIT OpenCourseWare - 83Project: write, circulate and land a real design docMalte Ubl
Prove it: Production ownership
A real design document for a change to a system you work on, reviewed by at least two engineers, plus at least three ADRs recording decisions from it, and the review comments with how you resolved each. Judge the design doc against this rubric: (1) the context and problem are clear to someone outside the team in the first page; (2) goals and non-goals are explicit and testable; (3) at least two genuine alternatives are described fairly, with the reason each was rejected; (4) risks, failure modes, migration and rollback are addressed; (5) there is a rough estimate with stated assumptions; (6) it is as short as it can be (most good design docs are 3 to 10 pages). Judge each ADR on: one decision, its context, the options, the decision and its consequences, written so it still makes sense in two years. It is good when reviewers changed the design and you can show where. It is not good if it was written after the code to justify what was already built.
Expert, two levels above the hire line
2 stages · learned alongside your job
12
Technical leadership: reviews, mentoring, incidents and influence
You can raise the effectiveness of the engineers around you: lead incidents and postmortems, set the standard for code review, mentor others, give hard feedback, and move decisions you do not control.
Practice7 lessons · about 4 weeksOrg impact- 84
Leading an incident as incident commanderPagerDuty Inc. - 85
Facilitating blameless postmortemsBran van der Meer - 86Setting the standard for code reviewGoogle
- 87
Mentoring other engineersLeadDev - 88
Giving feedback and handling frictionTED - 89
Managing technical debt deliberatelyModern Software Engineering - 90
Influencing without authorityLeadDev
Prove it: Org impact
A leadership record for your team covering at least six months: a postmortem you facilitated, with its action items and their status; a code review guide or standard you wrote and the team adopted; a mentoring log for at least one engineer, with goals agreed at the start and what changed; and a written case where you changed a technical decision you did not own. It is good when: the postmortem is blameless and its action items address system causes, not individuals; the review guide is actually referenced in reviews; your mentee or their manager can describe a specific skill they gained; and the influence case shows how you built agreement (who you talked to, what objections you addressed), not just that you were right. Ask a peer and your manager to confirm each item. It is not good if every item depended on your title rather than your work.
- 84
13
Staff-level impact and technical strategy
You can identify the technical work that matters most to your organisation, set direction for it across teams, and see it through to an outcome other people can name.
Practice8 lessons · about 3 weeksOrg impact- 91
What staff engineers actually doLeadDev - 92
Choosing what to work onThe Pragmatic Engineer - 93
Writing technical strategy and visionWill Larson - 94Choosing technology for the long termDan McKinley
- 95Leading large migrationsWill Larson
- 96
Working with leadership and productThe Pragmatic Engineer - 97
The IC and management pathsOptionalInfoQ - 98Milestone: an impact review against a real ladder
Prove it: Org impact
A staff-level impact portfolio: a written technical strategy or vision for an area spanning at least two teams, and evidence of one cross-team initiative you led from proposal to outcome (a migration, a platform, a reliability programme). It is good when: the strategy diagnoses a real problem, states guiding policies and makes choices that rule things out (a strategy that says yes to everything is not one); leadership and the affected teams have read it and act on it; the initiative has a measurable outcome (adoption, incidents avoided, delivery time, cost) that people outside your team can name; and you can show what you chose not to work on and why. Have a staff or principal engineer, or your director, review the portfolio against your company's ladder or a public one such as Dropbox's. It is not good if the impact depended on a single heroic push rather than a change that outlasts you.
- 91
About this track
Most learning paths stop at 'getting started', or at best at the first job. This one follows the whole career of a web-focused software engineer, because the skills that decide how far you go are the ones nobody teaches after the first tutorial: writing design documents, leading incidents, reviewing code well, estimating honestly, mentoring and influencing decisions you do not own.
The roadmap runs in order. First the basics of programming and problem solving in JavaScript. Then building real web software across the stack, with TypeScript, React, Node and PostgreSQL. Then the professional practice juniors are actually judged on: testing, pull requests, code review, security and CI. Then a portfolio piece and the job search. After the hire line it keeps going: system design and architecture, running production, design docs, RFCs and ADRs, technical leadership, and finally staff-level strategy and impact. Every phase ends in something you produce, not something you watched. Before the first job that is code and deployed applications. After it, the evidence is work done on real systems: an architecture review, an operations pack, a reviewed design document, a postmortem you facilitated, a strategy that teams follow. Watching the videos earns nothing on its own. Everything here is free: YouTube, official documentation and a few well-known free books and guides. Every link was checked before it was written down. Where only part of a long video is relevant, the note gives the timestamps.