How the Work Works

You know which role this path is teaching you toward. This lesson is about how you actually learn it, because the structure of the work is deliberate. One of the biggest lessons I have learned as an engineer is that real learning happens when you hit a problem and work your way through it.

The lessons introduce the ideas and show the techniques. The quizzes, projects, and capstone are where you put them into practice — the way you would on the job.

Three kinds of work

Throughout the paths, you will complete three types of work:

  • Quizzes check your understanding of a few lessons while the concepts are still fresh.
  • Projects give you guided practice applying a module’s concepts to a complete deliverable.
  • The capstone brings everything together in one independent, end-to-end project.

The amount of guidance changes as you progress. Early work gives you more support; later work gives you more ownership.

Projects

Each module includes one project where you build the type of system that module introduces. The lessons use worked examples to demonstrate each technique; the projects are where you apply those techniques yourself, working with your assigned project dataset.

You carry this project through every module, expanding it as you develop new skills. By the end, you will have a complete system that grew alongside your understanding. Each finished project also goes on your portfolio site — the page you set up in a later lesson of this module — so the work is not just graded and forgotten; it accumulates into a public record you can point an employer at. The upcoming modules return to this, adding each module’s deliverable to the portfolio as you complete it.

The structure reflects how real engineering work happens:

  • You build in your own GitHub repository. A finished project that demonstrates your ability to build, explain, and maintain a working system.
  • You start from a reliable foundation at each phase. Starter repositories give you a known-good starting point, so you focus on new skills rather than repeating setup.
  • You work with real tools and practices. Later projects introduce Docker, APIs, cloud deployment, infrastructure as code, monitoring, and CI, completed in your own environment and cloud account.
  • You build each module’s work on its own branch. Rather than changing the main version directly, you create a branch for the module, build there, and merge it back once it is ready — the same workflow professional teams use to keep a working version safe. The first module teaches this in full.
  • You submit through your repository. Once your work meets the requirements, you push your changes and submit the repository URL.

Each project page includes the required tasks and a rubric, so you have a clear standard: what should work, what should be included, and which engineering practices should be demonstrated.

The capstone

At the end of the path, you build a complete ML product from start to finish. You choose a new dataset and apply everything you developed: data preparation, modeling, a serving API, a frontend, cloud deployment, infrastructure, monitoring, and retraining.

The capstone is intentionally open-ended. The earlier projects give you structure; the capstone gives you a problem. You decide how to approach it, which tradeoffs to make, and how to design a system that reflects your own engineering judgment.

The goal is not to finish one more project. It is to demonstrate that you can take an idea from data through deployment and operation — a project you can discuss in interviews and keep improving after the path ends. The capstone becomes the centerpiece of your portfolio site: the one end-to-end system that shows, in a single place, everything the path taught you to do.