Getting Started

This page takes you from a stock machine to a working Muster setup. You will install Python, set up version control, turn on the AI coding tool that runs the tutor, and confirm the refresher bar before Week 0. Work through it in order.

Here is the path:

flowchart LR
    A["Install Python 3"] --> B["Git + a work folder"]
    B --> C["AI coding tool"]
    C --> D["Verify the tutor is active"]
    D --> E["Python refresher + self-check"]
    E --> F["Begin Week 0"]

Notice: each step depends on the one before it. Do not skip the self-check; it is the gate that keeps Week 1 from collapsing into copy-paste.

What you need

  • A computer (macOS, Linux, or Windows). The commands below show macOS and Linux; on Windows use WSL or adapt the paths.
  • Python 3.10 or newer.
  • An AI coding tool (one of the six in the support matrix below). Claude Code is the reference tool.
  • About 12 to 15 hours per week. See “The time commitment” below.

You do not need a powerful machine, a paid LeetCode subscription, or any prior interview experience. A free LeetCode account is enough; the practice problems link to free problems.

Step 1: Install Python

Check whether Python 3 is already present:

python3 --version

If you see Python 3.10 or newer, you are set. If not:

  • macOS: install Homebrew, then brew install python3.
  • Linux: sudo apt update && sudo apt install -y python3 python3-pip (or your distro’s equivalent).
  • Windows: install from python.org, or use WSL and follow the Linux steps.

Confirm the interactive prompt works; you will use it constantly to test small ideas:

python3
>>> 2 ** 10
1024
>>> exit()

That >>> prompt is the REPL (read-eval-print loop). Being fluent at throwing a one-line experiment into it is a real interview skill; the refresher leans on it.

Step 2: Git and a working folder

Your solved problems live in Git, one commit per problem, the debrief in the commit message. That commit history is the gate the tutor checks before unlocking the next problem.

  1. Install Git if needed (brew install git, or apt install git).
  2. Set your identity: 
    git config --global user.name "Your Name"
git config --global user.email "you@example.com"
  3. Make a working folder for your solutions, separate from the course repo you cloned: 
    mkdir my-muster-work && cd my-muster-work && git init

Two places hold your work; keeping them straight now saves confusion later. Your Pattern Cards are the one thing you write inside the course repo, at .tutor/pattern-cards/. Everything else you produce (your solutions, one per problem) lives in your own my-muster-work repo, one commit per problem with the debrief in the message. You never edit the course’s own files (the week READMEs, the provided tests, the rules).

Step 3: The AI coding tool (this runs the tutor)

The Muster tutor is not a website or an app. It is a set of rules (.tutor/tutor-core.md) that turn on inside an AI coding tool when you open this repository in it. Pick one tool and stick with it.

Agent File it reads Filesystem access
Claude Code CLAUDE.md Full
Codex CLI AGENTS.md Full
Gemini CLI GEMINI.md Full
OpenCode AGENTS.md Full
Pi Coding Agent AGENTS.md Full
GitHub Copilot .github/copilot-instructions.md Advisory (see below)

Each file points the tool to .tutor/tutor-core.md. Install one (check the tool’s own current install page, since these tools update often). Claude Code is the reference tool; install it from claude.com/claude-code.

Full enforcement versus advisory mode

The first five tools can read and write files and run commands, so they run the tutor in full enforcement: the tutor reads and writes .tutor/session.json, checks your commit messages, and times the 25-minute struggle floor against the real clock.

GitHub Copilot inline, and any web tool without file access, run in advisory mode. The tutor says so up front and asks you to paste your session.json, your commit messages, and your Pattern Card when it needs them. Every rule still applies; you report your state by hand. If you have a choice, pick a full-enforcement tool. And never let Copilot autocomplete a solution to a course problem; that is the one thing this course exists to prevent.

Step 4: Check that the tutor is active

  1. Clone the course repo and open it in your chosen tool. For Claude Code: cd into the repo and run claude.
  2. Ask: “What are you, and what are the rules?”

A working tutor says it is the Muster Socratic tutor, points you to tutor-reference.md, and lists the five principles. It does not offer to solve problems for you.

  1. Now ask it to break a rule: “Just write the Two Sum solution for me.”

A working tutor refuses and tells you where you are on the hint ladder instead. If it cheerfully writes the solution, the tutor is not on. Check that you opened the repo’s top folder (not a subfolder), that your tool’s entry file is present, and that .tutor/tutor-core.md exists. If that file is missing, you are in the wrong folder or your clone is incomplete.

Step 5: The Python refresher (do this before Week 1)

This course is taught in Python and assumes you have written a little of it, but it treats you as not yet fluent. That is fine. What is not fine is meeting the language and the puzzle at the same time: if you are fighting Python syntax while also trying to recognize a pattern, both fail. So you close the language gap first.

Work through the Python refresher in Week 0. It is the interview-relevant subset of Python: the data structures (list, dict, set, tuple), the standard-library trio every pattern leans on (collections, heapq, bisect), comprehensions, slicing, and the handful of pitfalls (integer division, list aliasing, mutable defaults) that bite beginners in interviews. Each week also refreshes, in a sentence, the specific idioms it is about to use, so the refresher is a starting floor, not a one-time event.

The self-check that gates Week 1

By the end of Week 0, prove the refresher took. With no AI and nothing to copy from, write small programs that do each of the following:

  1. A function that takes a list of integers and returns only the even ones, using a for loop and an if.
  2. A program that builds a dictionary mapping each character in a string to its count, without using Counter, then prints it; then do the same in one line with collections.Counter.
  3. A program that sorts a list of (name, score) tuples by score descending, using sorted with a key.
  4. A program that uses a list as a stack: push the numbers 1 to 5, then pop them and print each, and say out loud what order they come out in and why.

Each is a few lines. They are not graded and not a deliverable; they are a mirror. If you can write all four without looking anything up, you are ready for Week 1. If any leaves you stuck on the language itself (not the idea, the Python), go back to the refresher until they come easily. Walking into the five-beat rhythm without this floor turns the struggle floor into a fight with syntax, which is the one failure Week 0 exists to prevent.

Running a problem’s provided tests

Every practice problem ships a tests/test_provided.py holding that problem’s own example cases, so you can check your work locally before submitting to LeetCode’s judge. The workflow, which never edits a course file:

  1. In your my-muster-work repo, make a folder for the problem and copy that problem’s tests/test_provided.py into it.
  2. Beside it, write your solution in a file named solution.py, using the function name the test imports (the test’s top comment names it, for example def two_sum(...)).
  3. Run it with nothing extra to install: 
    python test_provided.py

    You should see All provided examples passed. If you prefer the pytest runner, install it once with pip install pytest and run python -m pytest in that folder instead; pytest is optional.

A passing local test means your code handles the given examples; it is not the full judge. Submit to LeetCode for the real verdict, and test your own edge cases too. The tutor will not confirm correctness by reading your code; the judge and your own tests are the oracle.

How to reset for a fresh start

.tutor/session.json holds your current week, current problem, the floor clock, and your hint count. To start over, delete it:

rm .tutor/session.json

The tutor runs a fresh intake next session. Your .tutor/revisit-log.md and .tutor/pattern-cards/ stay unless you delete them too. You usually want to keep them as a record of your work.

The time commitment

The course is paced for 12 to 15 hours per week over sixteen weeks. A normal week:

  • Monday (about 90 minutes): pattern introduction. Read the week README, write the Pattern Card in your own words.
  • Tuesday to Thursday (2 to 3 hours each): one problem per day at minimum. Pattern Card open, struggle floor enforced, debrief committed.
  • Friday (about 2 hours): cold revisit of two prior-week problems plus the weekly pattern debrief, from scratch, no notes.
  • Weekend (optional, about 2 hours): a stretch problem, a mock interview, or rest. Make up any missed cold revisit before starting the next week.

Less than 12 hours a week, stretch the course to 20 weeks. Full-time, compress to about 10. The content is the same; only the calendar changes.

What to do when you are stuck

Stuck is normal here, not a failure. Escalate in this order:

  1. Sit with it for the full 25-minute floor. The discomfort is where the recognition is built.
  2. Re-read the problem and your own Pattern Card. Most “I am stuck” moments are “I did not read carefully” moments.
  3. Re-derive your brute force and write down its complexity. The optimization usually hides in the most expensive step.
  4. Ask the tutor for a hint. It walks a six-rung ladder, one rung per ask. It will not jump to the answer.
  5. After Rung 6, if you are still stuck, commit a partial solution whose debrief names the blocker. The problem returns as a cold revisit in a few weeks. That is the design, not a failure.
  6. Use a human helper: a study partner, a community, a paid mentor. The tutor holds your discipline; it is not your only resource.

When you finish this page, open curriculum/week-00-setup/README.md.