PatternsPractice and reference
Review worksheets
Fill in this worksheet after a real attempt at a problem. On later reviews, keep the answers covered until you've tried to recall them.
| Field | Your notes |
|---|---|
| Problem and date | |
| Solved alone, or with help | |
| Simple solution that works | |
| Repeated or unneeded work | |
| Idea that removes it | |
| Assumptions it needs | |
| State, or what stays true | |
| Why each step keeps it correct | |
| Time and space cost | |
| Smallest example that breaks my first idea | |
| Coding mistake | |
| Variation to try next | |
| How the later review went |
To add a new explanation to this guide, include: the exact problem, how to work out the solution, what stays true (or the recurrence), the cost and its assumptions, where the method breaks, and a practice link. Link to the original problem statements and respect their licenses. Show another approach only when it teaches a different decision, and compare the approaches instead of just listing code.
Keep the problem list separate from what you've mastered. A solution existing in the repository doesn't mean you understand it, and passing an example doesn't prove a solution is correct. A version covering every problem should keep the different valid approaches, and mark which explanations were reviewed and which were generated.
When you add a group of problems, test the explanation against an example that works and one that breaks it. When you add a new exercise, check its examples, edge cases, and reference solution against a simple separate solution on small inputs. A reworded story still needs an exact problem statement.