How the course builds connections
The current course has 218 short lessons spanning DSA, low-level design, and high-level design. The feed shows only one small step at a time, with at most 32 explanatory words. Mental models, complete Python examples, and architecture walkthroughs open only when requested. Prerequisites are included when you choose a topic, and can be skipped.
What progress means
You can read a new problem, state what information matters, propose a baseline, and justify a better approach. Naming a familiar algorithm is useful only if you can explain why its assumptions hold.
We use “build connections” to mean observable skills: predicting behavior, explaining a recurrence, recognizing a shared structure in a new story, and finding a counterexample. The course makes no claim to measure new neurons or guarantee a biological change.
The card loop
- Picture: one concrete situation and one claim. The feed divides it into small steps; the full notes can use a longer paragraph.
- Predict: a small decision before seeing an answer. Saying “I don’t know” is valid.
- Reveal: show the reasoning and explain the tempting mistake.
- Go deeper: trace, precise model, Python experiment, cost, and the limit of the analogy.
- Change one rule: determine whether the same reasoning still works.
- Connect: name the relationship to an earlier or later concept.
Predictions are intended to make the learner retrieve or construct an explanation. A primary study found retrieval benefits on conceptual and inference questions in its learning setting; that supports including retrieval, but does not establish a particular swipe interface or a guaranteed DSA outcome. Karpicke and Blunt, 2011.
The five questions to reconstruct
Use these before coding. You do not have to remember their order.
| Question | Evidence to produce |
|---|---|
| What is the answer asking for? | Existence, count, an optimum value, one construction, or every construction |
| What describes a remaining problem? | A state sentence and two histories that should or should not merge |
| What are my choices and dependencies? | A tiny search tree or transition sketch |
| What work can I avoid, and why? | Repeated state, monotone boundary, invalid branch, or proved safe choice |
| Can it fit the constraints? | Number of states × work per state, plus storage and output cost |
These questions are a reasoning aid, not a decision tree that guarantees a unique algorithm. Several approaches may be valid; input size and desired output often decide between them.
Practice and review
One optional rhythm: recall an old idea, explore up to three new cards, then change one rule in a tiny example. Try saying “I chose ___ because ___. It would stop applying if ___.” You can think or speak the answer; typing and quiz completion are never required to continue.
Use next-day, three-day, and one-week reviews as an initial product heuristic, not a scientifically optimal schedule. On an unsuccessful review, revisit the relevant prerequisite and retry a simpler example. On a successful review, change the surface story or a constraint. The exact schedule should remain adjustable.
Avoid turning time spent scrolling into a learning score. Track different evidence separately:
- Seen: opened the idea.
- Explained: produced a reasonable model after thinking.
- Applied: solved a small variant and explained the assumptions.
- Transferred: handled an unlabeled problem with a changed surface story.
- Retained: did that again after a delay.
These are progress descriptors, not medical or psychometric measurements. Self-ratings should not pretend to prove correctness.
How feedback should work
For a wrong prediction, show a minimal counterexample, then ask which assumption failed. For wrong code, trace the first incorrect state before showing a full reference solution. Hints progress from a question about the state, to a small diagram, to a recurrence, and only then code.
Mixed practice hides topic names until the explanation is revealed. Otherwise the label “2D DP” gives away the very decision you are learning to make.
An analogy must also explain where it stops working. A family tree helps introduce hierarchy, but a binary search tree additionally has a value-ordering invariant. A city map helps introduce graphs, but some graph vertices are entire situations such as (location, fuel_left).