Self-Assessment¶

Everything here is a self-study tool. Nothing is submitted, nothing is marked by anyone but you, and nothing is timed unless you choose to time it. The point is to find out what you actually know, while it is still cheap to fix.

The whole system is built on one habit: write your answer down before you check it. Reading a solution feels like understanding and produces none.

What is available¶

Per module¶

Tool	Covers	Questions	Where
Module quiz	one module	10	Quizzes

Across the course¶

Tool	What it trains	Questions	Length
Concept checks	rapid recall — the name or the rule, not the mechanism	36 short answers	40 minutes
Code tracing	reading a program and committing to a prediction	12 programs	60 minutes
Debugging	finding the defect, and saying when it bites	12 broken programs	60 minutes
Design questions	making design decisions and stating a trade-off	10 open designs	2–3 hours
Final comprehensive assessment	everything at once, as a closing check	25 mixed	90 minutes, closed-book

In total the course holds over 250 self-check questions — 160 in the module quizzes, 36 concept checks, 12 traces, 12 debugging problems, 10 designs and 25 in the final assessment — spanning every module and every difficulty from recall to open design.

For exam-style timing¶

If you also sit a graded exam, these practice papers are timed and marked out of a total. They are optional: the self-assessment tools above are the ones designed for learning.

Paper	Covers	Suggested time
Practice midterm 1	Modules 1–8	90 minutes
Practice midterm 2	Modules 9–12	90 minutes
Practice final	Modules 1–16	3 hours
Capstone rubric	Module 16	At project end

Every paper is self-contained. Where a question asks you to trace, predict or debug a program, that program is printed on the page beneath the question, so there is nothing to download and no starter file to assemble before you can begin. Timing is what the papers test, so they are written to be worked from one page.

Where the answers are¶

Answer keys are separated from the questions on purpose, in two places:

docs/quizzes/answers/            one key per module quiz
docs/assessments/answer-keys/    one key per cross-course page

An answer you read before attempting the question converts a diagnostic into a reading exercise. The honest sequence is: answer first, then check the key, then study only the questions you got wrong. Nothing else in this course rewards patience as directly.

Every answer explains why it is right. For code questions the explanation says which function is called and why; for design questions it states the trade-off accepted. Where a result is implementation-defined, the key says so rather than inventing a guarantee.

Marking yourself¶

Score each page as: correct answers ÷ total questions, counted honestly. A partial answer scores half; \"I sort of knew it\" scores nothing — that is precisely the state an exam punishes.

For the design questions, score each part of a good answer separately: the types named (1), each relationship justified (1), the trade-off stated (1).

Score	What it means	What to do next
90–100%	Ready for advanced work	Move on to the next module, the capstone, or the harder labs. Keep the misses as a short review list.
75–89%	Review weak areas	Read the specific lesson sections the misses point at, then re-answer those questions a week later. Do not re-read the whole module.
60–74%	Practice required	Re-do the module's lab and its exercises before moving on. The gap is usually in doing, not in reading.
Below 60%	Revisit the module	Work through the module again from its lessons, then reattempt. Moving on now costs more time later than it saves.

Two rules make the score useful:

Score the reason, not the letter. A right answer with wrong reasoning is a miss. This is why the keys explain rather than merely state.

Re-test the misses, later. Wait at least a week, answer them again from memory, and only then count them as learned. Anything you still miss has not been learned, whatever the score said the first time.

Technique for closed-book work¶

These matter more than most students expect, because a large share of lost marks in a C++ paper is lost to things that are not knowledge.

Read the code, do not run it in your head at full speed. For any question involving object lifetime, write down the order of construction and destruction explicitly. Most errors in this course come from skipping that step.

For \"what does this print?\" questions, look for the trap first. Slicing, non-virtual destructors and copy counts are never in a question by accident. If a derived object is passed by value, the answer is probably about slicing. If a pointer is deleted through a base class, look at the destructor. If a virtual is called from a constructor, look at which version runs.

For \"find the bug\" questions, check in this order:

Object lifetime — is anything used after it is destroyed, or freed twice?
virtual — is a polymorphic base missing a virtual destructor, or a function missing virtual?
Copying — is an owning class relying on a compiler-generated copy?
const — is a non-const member function called on a const object?
Ownership — does anything own what it should not?

For design questions, answer in a shape. State the design, then the reason, then the trade-off you accepted. A named principle (single responsibility, dependency inversion) earns credit when it genuinely applies — and loses it when applied as decoration.

For code-writing questions, write code that compiles. Prefer clear, correct and simple over clever. A working solution with obvious ownership beats a clever one with an ambiguous lifetime.

Attempt every part. Marks are distributed across many small questions; a blank answer to \"state the Rule of Three\" is a certainty, whereas a partial answer is often most of it.

Building a revision routine¶

If you have one to three weeks, follow the Revision plan in Study Plan. In short:

Work through Reading Compiler Errors until diagnosis is fast. Closed-book work punishes slow debugging.
Work through the concept checks — they find gaps in minutes.
Work through the code tracing and debugging pages.
Rewrite the labs you rushed, from a blank file. Reading a solution is not revision; rewriting it is.
Write one-page summaries per module from memory, then correct them against the module.
Re-answer every question you got wrong, without looking at the key first.

Related: Quizzes · Exercises · Cheat Sheets · Glossary · Study Plan