Checkpoint Gate: After Semester 2
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Closed-book prompts, self-assessment answers, and skills matrices | Practice artifact | Use for honest calibration; do not publish raw answers unless rewritten as a study guide. |
| Required evidence gate items, sign-off checklist, and readiness decision | Checkpoint evidence | Keep as private progression evidence; share only sanitized summaries with mentors or reviewers. |
| Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooks | Checkpoint evidence | Store beside the checkpoint so the remediation trail is inspectable without making mistakes public. |
| Reviewer notes or mentor feedback that materially improve a project artifact | Portfolio candidate | Convert into public-safe acknowledgements or changelog entries only after removing private feedback context. |
caution
Do not advance to Semester 3 until you can clear this gate without leaning on solution videos, copied code, or memorized traces. The goal is algorithmic judgment, not checklist completion.
What this gate is testing
By the end of Semester 2, you should be able to:
- analyze runtime and space costs for unfamiliar code
- choose an algorithmic paradigm based on problem structure
- implement core data structures and algorithms correctly
- justify why a solution is correct, not just that it seems to work
- compare theoretical complexity with empirical benchmark behavior
Knowledge checks
Clear every item before you move on.
- Module 1: Algorithm analysis and design. I can explain Big-O, Theta, and Omega in plain language; count loop costs; write and solve simple recurrences; and explain why divide-and-conquer helps on some problems but not others.
- Module 1: Correctness reasoning. I can write a short invariant or proof sketch for binary search, merge sort, or another core algorithm without copying textbook phrasing.
- Module 2: Sorting and searching. I can implement merge sort, quicksort, heap sort, and binary search; compare stability, memory use, worst-case behavior, and practical tradeoffs.
- Module 2: Fundamental structures. I can explain when to prefer arrays, heaps, hash-backed structures, and ordered-tree-backed structures.
- Module 3: Graph algorithms. I can choose between BFS, DFS, Dijkstra, and minimum spanning tree approaches based on graph properties and the question being asked.
- Module 3: Graph modeling. I can represent graphs using adjacency lists or matrices and explain the cost tradeoffs of each.
- Module 4: Dynamic programming. I can identify overlapping subproblems and optimal substructure, derive a recurrence, and move from brute force to memoization to tabulation.
- Module 4: Greedy vs DP. I can explain at least two problems where a greedy strategy works and two where it fails unless dynamic programming is used.
- Module 5: Advanced structures. I can explain the purpose of balanced trees, disjoint-set union, heaps, and amortized analysis, and I can describe the operations each structure is meant to optimize.
- Module 5: Amortized reasoning. I can explain why an operation may be expensive occasionally but still cheap on average over a sequence.
Skills checks
You should be able to perform these without heavy prompting.
- Trace a recurrence tree and estimate its asymptotic growth.
- Read a novel code snippet and classify the dominant cost correctly.
- Build a benchmark that compares at least two competing implementations fairly.
- Write tests that catch edge cases for sorts, searches, graphs, and set-like operations.
- Classify a new problem as divide-and-conquer, graph traversal, greedy, dynamic programming, or advanced-structure-heavy, and justify the classification.
- Explain one algorithm choice using both theory and observed benchmark results.
Required evidence
You are not ready on intuition alone. Produce the artifacts.
- All module quizzes attempted across Modules 1 through 5.
- An algorithms repository with tested implementations from every module.
- At least one benchmark report comparing multiple implementations or data structures.
- A short write-up on one graph problem and one dynamic programming problem, including why the chosen approach fits.
- A spaced-repetition deck covering asymptotics, recurrences, graph patterns, DP patterns, and amortized analysis vocabulary.
- One reviewed commit history showing disciplined iteration rather than a single large dump.
Common blockers
Do not advance if any of these are still true.
- You are choosing data structures by habit instead of operation cost.
- You can trace textbook examples but freeze on slightly altered inputs.
- You know recurrence patterns by memory but cannot derive one from a new recursive algorithm.
- You can implement dynamic programming only after seeing the final state definition.
- You describe amortized analysis as "average case" without being precise about the operation sequence.
Remediation path
If you miss the gate, repair the weakness directly.
- Rework Module 1 drills if asymptotics, recurrences, or proof sketches still feel unstable.
- Re-implement Module 2 sorting and searching algorithms from scratch with tests and edge-case notes.
- Do two fresh graph traces by hand from Module 3 before reopening code.
- Rewrite one brute-force solution into memoized and tabulated versions from Module 4.
- Rebuild union-find and one balanced-search-tree abstraction from Module 5, then explain the operation costs in your own words.
Sign-off
Record the date you passed this gate and the weakest area you still plan to revisit during Semester 3. Advancing is acceptable only when the remaining weakness is speed or polish, not conceptual confusion.
Mastery Rubric
| Level | Evidence |
|---|---|
| Beginner pass | Can answer direct questions and complete familiar exercises with light notes. |
| Solid pass | Can solve new variants, explain choices, and connect the work to Semester 1 Mathematical and CS Foundations. |
| Strong pass | Can defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact. |
| Not ready | Relies on copied solutions, cannot explain mistakes, or lacks durable artifacts. |
Retake and Repair Rule
If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.
Answer-Quality Examples
Use these examples when grading written answers or spoken explanations.
| Quality | Example pattern |
|---|---|
| Weak | Names a concept but gives no example, constraint, or failure case. |
| Acceptable | Defines the concept and applies it to a familiar exercise. |
| Strong | Applies the concept to a new variant and explains why an alternative would fail. |
| Portfolio-ready | Connects the concept to Semester 1 Mathematical and CS Foundations, current project evidence, and a future capstone decision. |
Interleaving Prompt
For any missed answer, add one sentence starting with: This depends on an earlier skill because...
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: