Skip to main content

Checkpoint Gate

Required Output Classification​

Required outputClassificationPublic/private guidance
Closed-book prompts, self-assessment answers, and skills matricesPractice artifactUse for honest calibration; do not publish raw answers unless rewritten as a study guide.
Required evidence gate items, sign-off checklist, and readiness decisionCheckpoint evidenceKeep 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 runbooksCheckpoint evidenceStore beside the checkpoint so the remediation trail is inspectable without making mistakes public.
Reviewer notes or mentor feedback that materially improve a project artifactPortfolio candidateConvert into public-safe acknowledgements or changelog entries only after removing private feedback context.

Use this gate after finishing the module quizzes and before starting Semester 5. The goal is not to reward speed. The goal is to stop you from carrying fuzzy systems knowledge into operating systems and networking.

Instructions​

  • Answer from memory first.
  • Mark Confident only if you can explain the idea and demonstrate it at the keyboard.
  • Mark Review needed if you would need to search or guess.
  • Any weak answer in Modules 2-4 should be treated as a real blocker.

Knowledge Checks​

Module 1: C Programming Fundamentals​

  1. I can explain the difference between preprocessing, compiling, assembling, and linking. - [ ] Confident [ ] Review needed
  2. I can explain declarations vs definitions, header discipline, and what the linker resolves. - [ ] Confident [ ] Review needed
  3. I can explain array-to-pointer decay and why C strings fail when buffer boundaries are ignored. - [ ] Confident [ ] Review needed

Module 2: Memory, Pointers & Machine Representation​

  1. I can draw the stack, heap, globals, and code region for a small C program and place objects correctly. - [ ] Confident [ ] Review needed
  2. I can explain pointer arithmetic, struct padding, endianness, and at least three memory-safety bugs. - [ ] Confident [ ] Review needed
  3. I can explain what ASan or Valgrind reported in one of my own debugging sessions. - [ ] Confident [ ] Review needed

Module 3: Computer Organization & Architecture​

  1. I can read short disassembly and match it back to loops, branches, and function calls in the source. - [ ] Confident [ ] Review needed
  2. I can explain cache locality, branch prediction, and why asymptotically similar code can run at very different speeds. - [ ] Confident [ ] Review needed
  3. I can explain virtual memory at the level of pages, page tables, and the TLB without confusing them. - [ ] Confident [ ] Review needed

Module 4: Systems-Level Programming​

  1. I can write fork + exec + waitpid from memory and explain the parent/child flow. - [ ] Confident [ ] Review needed
  2. I can explain file descriptors, dup2, pipe, and how shell redirection actually works. - [ ] Confident [ ] Review needed
  3. I can explain thread races, mutexes, condition variables, sockets, and when to use gdb, strace, or perf. - [ ] Confident [ ] Review needed

Module 5: Abstraction & Interpretation​

  1. I can explain closures, the environment model, tail calls, and the split between eval and apply. - [ ] Confident [ ] Review needed
  2. I can connect interpreter design back to the low-level execution model from Modules 1-4. - [ ] Confident [ ] Review needed

Skills Checks​

  1. I can compile a multi-file C project with warnings enabled and fix the warnings instead of ignoring them. - [ ] Confident [ ] Review needed
  2. I can debug one crash or memory bug from first reproduction to root cause using tools, not only print statements. - [ ] Confident [ ] Review needed
  3. I can build a small UNIX-style tool that opens files, processes bytes, and reports errors correctly. - [ ] Confident [ ] Review needed
  4. I can produce one benchmark or systems measurement and explain what the result means. - [ ] Confident [ ] Review needed
  5. I can explain one real design tradeoff between low-level control and abstraction cleanliness. - [ ] Confident [ ] Review needed

Required Evidence​

Before checking yourself ready, verify that you have:

  • a buildable C project with more than one translation unit
  • at least one sanitizer or debugger transcript from a real bug
  • at least one disassembly or cache-analysis note you wrote yourself
  • at least one fork/pipe/dup2 exercise that you can still explain from memory
  • at least one closure or interpreter exercise from Module 5

If any of those artifacts are missing, the semester is not complete even if the quizzes look fine.

Blockers To Clear Before Semester 5​

Do not move on yet if any of these are true:

  • you still guess about pointer behavior instead of drawing memory
  • you cannot explain why a compiler warning matters
  • you cannot read a simple strace or gdb backtrace
  • you know the words cache or virtual memory but cannot apply them to an example
  • you can write thread code but cannot argue why it is race-free

Sign-Off​

  • I completed the cumulative review
  • I completed the semester project
  • I can defend my weakest module and have a repair plan if needed
  • I am ready to begin Semester 5: Operating Systems and Networking

Mastery Rubric​

LevelEvidence
Beginner passCan answer direct questions and complete familiar exercises with light notes.
Solid passCan solve new variants, explain choices, and connect the work to Semester 3 Software Design.
Strong passCan defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not readyRelies 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.

QualityExample pattern
WeakNames a concept but gives no example, constraint, or failure case.
AcceptableDefines the concept and applies it to a familiar exercise.
StrongApplies the concept to a new variant and explains why an alternative would fail.
Portfolio-readyConnects the concept to Semester 3 Software Design, 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: