Projects & Capstones

I have reviewed enough portfolios to know that what separates a strong one from a weak one is not the number of projects — it is whether the engineer can talk about every line of code and every decision. This curriculum is structured so that by the end, you can. Every module has projects that test individual lessons and a capstone that tests the whole module. Here is exactly how they work.

Two kinds of work

Projects appear throughout each module, one after each lesson or pair of lessons. They are scoped to what you have covered so far — a project after lesson 3 only tests lessons 1–3. They are gatekeepers: you must complete the project before the next lesson unlocks. This is not to be difficult. It is because each lesson assumes you can apply the previous one, and the project is how you verify that.

Capstones appear at the end of each module. They test everything. No starter code, no guided steps — just requirements, a blank editor, and what you know. A capstone is a GitHub repository you own, build, and submit. It is the evidence that the module’s concepts are usable knowledge, not just recognised vocabulary.

How projects work

Each project tests the lesson immediately before it. The scope is narrow — a project after lesson 3 only tests what lessons 1–3 covered. Projects are gatekeepers: the next lesson does not unlock until you submit.

Each project page gives you:

  • A starter repo — a GitHub repository with scaffolding already in place: directory structure, stub functions with type signatures, and a test suite. You fork it, fill in the implementation, and make the tests pass.
  • Requirements — what the system must do, in terms of inputs, outputs, and behaviour. No implementation hints — the starter gives you the shape, you supply the logic.
  • A submission field — paste your public GitHub repository URL and click Submit. The next lesson unlocks.

The workflow for every project:

# 1. Fork the starter repo on GitHub, then clone your fork
git clone https://github.com/<your-username>/<project-repo>.git
cd <project-repo>

# 2. Install dependencies
uv sync

# 3. Run the tests — they will fail until you implement the solution
uv run pytest

# 4. Implement, iterate until tests pass, commit and push
git add .
git commit -m "implement solution"
git push origin main

# 5. Submit your repo URL on the project page

The test suite tells you when the project is done. A passing test suite is the minimum bar — the project page also has a rubric with questions about design decisions, which you answer as part of the submission.

How capstones work

A capstone tests the entire module. The difference from a project: no starter scaffolding, no stub functions. You get requirements and a blank repository. The structure, the design, the tests — all yours.

Each capstone page has:

  • Requirements — written as a technical spec: what the system accepts, what it produces, what edge cases it must handle
  • A blank starter repo — a README.md with the requirements and a .github/workflows/ CI check. The CI check runs the same assertions as the rubric; it is not required to pass, but it tells you where you stand
  • A rubric — the questions a code reviewer would ask: does it do what it claims, is the design sound, could another engineer extend it

Capstones take longer. Budget a few hours, not a few minutes.

Submitting a project or capstone

The submission flow is the same for both:

  1. Go to the project or capstone page
  2. Paste your public GitHub repository URL into the submission field
  3. Click Submit

The URL is stored against your account. You can resubmit any time — if you improve the implementation, paste the updated URL and submit again. The field shows the last URL submitted and when.

Repositories must be public so the rubric can be applied. Make it public for submission, then private again if you prefer.

Adding to your portfolio

After submitting a capstone, add it to your portfolio site. Open index.html in your forked portfolio-starter repo and add an entry to the projects array:

{
  "title": "Plugin Export System",
  "description": "Type-safe Python export tool with a registry-based format selector. Handles CSV, JSON, and Parquet with pluggable serializers and a clean extension interface.",
  "repo": "https://github.com/your-username/capstone-plugin-export-system",
  "tags": ["python", "design-patterns", "refactoring"]
}

Keep the description specific — what does it do, what was the interesting problem, what would you do differently. Vague descriptions (“a Python project using OOP”) tell a reviewer nothing. Specific ones (“implements a type-safe plugin registry where each format serializer is registered by extension and selected at runtime”) show you understand what you built.

Commit and push. Your portfolio site redeploys automatically. Every capstone you complete should appear here by the time you finish the curriculum. That array is the thing you point to in an interview.