Skip to main content

Semester Exam

Required Output Classification​

Required outputClassificationPublic/private guidance
Timed written answers, diagrams, code snippets, and design responsesCheckpoint evidenceKeep raw exam work private so it remains useful for assessment and retake calibration.
Post-exam review notes, missed-answer repairs, and Feynman explanationsPractice artifactUse for spaced review; publish only rewritten explanations that no longer reveal exam solutions wholesale.
Capstone-defense or architecture-defense packets created from exam promptsPortfolio candidatePolish publicly only when they are original to your project, sanitized, and framed as engineering rationale rather than exam answers.

This is the integrated assessment for Semester 4. It should feel harder than any one module quiz because it tests whether the modules now connect into one mental model.

Format​

  • Duration: 3 hours
  • Resources: closed notes for Sections A and B; terminal, compiler, and debugger allowed for Section C
  • Deliverables: written answers, one or two diagrams, one short code artifact, and one debugging transcript or command log

Recommended pacing:

  • Section A: 45 minutes
  • Section B: 60 minutes
  • Section C: 75 minutes

Section A: Core Reasoning​

Answer in short paragraphs, diagrams, or annotated code fragments.

  1. Walk from hello.c to a running process. Name each transformation stage and the artifact it produces.
  2. Explain why an off-by-one write in a C string buffer can become a security or stability issue.
  3. Draw a small stack-and-heap memory diagram for a function that allocates memory, passes a pointer to another function, and then frees it.
  4. Explain the difference between a cache miss, a page fault, and a segmentation fault.
  5. Explain what happens to file descriptors across fork and why a shell must close unused pipe ends.
  6. Explain what a closure is and why lexical scope matters when implementing an interpreter.

Section B: Trace, Analyze, Defend​

Work these as explicit reasoning tasks. Do not skip the explanation.

  1. Given a short C function with a loop and branch, explain how you would confirm its machine-level behavior using compiler output or disassembly.
  2. Given a buggy C snippet with pointer arithmetic and heap allocation, identify the likely bug class, the expected symptom, and the first tool you would use.
  3. Given a matrix traversal example, predict which version is more cache-friendly and defend the claim.
  4. Given a shell pipeline sketch such as cat input.txt | wc -l, explain the parent/child process structure and the dup2 wiring.
  5. Given a producer-consumer sketch, identify one race that a mutex prevents and one condition that the condition variable protects.
  6. Given a tiny evaluator outline, explain which step belongs to eval, which belongs to apply, and where environments are stored.

Section C: Practical Systems Task​

Choose one of the following and complete it in code.

Option 1: UNIX Pipeline Tool​

Build a small C program that:

  • creates one child process
  • redirects one file or pipe endpoint with dup2
  • executes a standard UNIX command
  • waits for the child and reports the exit status

You must also include:

  • one command line showing how you compiled it
  • one short explanation of the file-descriptor state before and after redirection

Option 2: Memory Bug Investigation​

Start from a small buggy C program and:

  • reproduce the failure
  • use a debugger or sanitizer to identify the root cause
  • fix the bug
  • explain whether the original failure was due to bounds, lifetime, or representation reasoning

You must also include:

  • one transcript or command log from the tool you used
  • one short explanation of why the fix is actually correct

Option 3: Tiny Evaluator Extension​

Extend a tiny interpreter or evaluator so it supports one additional construct such as:

  • lexical bindings
  • conditionals
  • simple function application
  • mutation

You must also include:

  • one explanation of how environments or evaluation order changed
  • one note connecting the abstraction back to low-level execution costs

Scoring Standard​

Treat the exam as passed only if all of the following are true:

  • your written answers explain mechanisms, not just terms
  • your practical work compiles or runs cleanly enough to defend
  • you use at least one diagram, command, or debugger artifact to support your reasoning
  • your answers connect at least three modules instead of treating them as isolated topics

Post-Exam Review​

After finishing, write a short reflection:

  • Which module felt strongest?
  • Which module still slows you down in practice?
  • What would most likely break you in Semester 5 if you do not repair it now?

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: