Study Packs: How I Engineer Exam Prep

Every trimester, a few days before finals, my shortlinks start getting traffic. Classmates pass around my study packs for Human-Computer Interaction, Mobile Application Development, Software Engineering, and Machine Learning. They ask for them because the packs are engineered prep systems, not piles of notes.

Here's the method, using my HCI and Mobile App Development packs as examples. Steal it.

The core idea: a study pack answers a better question

A pile of notes answers "what was covered?" A study pack answers "what do I do with the time I have left?"

Every pack I build has the same five components.

1. Master index and study plan. The reading order, plus an explicit list of what to memorize versus what to skip. Deciding what to leave out is half the value.
2. Topic guides. One distilled guide per topic. For HCI that was exactly seven: ethics, research methods, data analysis, sketching, storyboarding, prototyping, and evaluation.
3. Solved past papers. Real questions with worked answers you can pattern-match against, instead of a vague instruction to review the slides.
4. A mock exam. A timed dry run. If you've never answered under time pressure, the real exam is where you find out you can't.
5. A cram sheet. The only thing you're allowed to read on exam morning. One pass, no rabbit holes.

Study the marks before the material

Before touching content, I work out where the marks actually come from, then let that decide the study order.

For my Mobile App Development final, the split was clear: React Native and NestJS questions were worth 16 of 20 marks. So the rule became: answer those first in the hall, and give them the most prep time. For HCI, the trap ran the other way. Everyone assumed the exam would be about their course project, but the project was only about a quarter of the paper. The pack's loudest warning: study broad across all seven topics and keep project answers ready as a bonus.

Both insights came from reading past papers before studying, not after. Requirements analysis, basically.

Write code from memory

For programming exams, re-reading solutions creates a dangerous illusion of competence. My MAD pack's plan is explicit: re-read the reusable component, the custom hook, and the CRUD controller, then write the to-do screen from memory once. On paper if the exam is on paper.

Reading code is recognition. Writing code is recall. Exams test recall.

The 60-minute "hour before" plan

The hour before an exam is high-leverage and universally wasted on anxious page-flipping. So every pack ends with a minute-by-minute plan. For MAD it looked like this:

• 0–18 min. React Native: props vs state, the reusable component, the custom hook. Write the to-do screen from memory.
• 18–36 min. NestJS: the external-API controller and service, the CRUD controller. Write the GET example once.
• 36–46 min. JS/TS essentials: event handlers, the TypeScript definition.
• 46–52 min. Git: init → add → commit → push, branching, one merge-conflict scenario.
• 52–60 min. Cram sheet, straight through. Breathe.

No decisions to make, no guilt about what you're skipping. The plan already decided.

Why building the pack is the real studying

Here's the secret: by the time the pack exists, I barely need it. Distilling seven topics into guides, choosing what to skip, writing model answers, and designing the mock is deep processing. The artifact is almost a by-product.

But the artifact is what compounds. Every classmate after me can reuse it, and it makes me the person people come to with questions, which is more forced recall practice. Teaching is the best way to learn. It's why I became a TA.

The takeaway

Treat exam prep like an engineering project. Understand the requirements (where the marks are), architect the system (index, guides, past papers, mock, cram sheet), test under load (a timed dry run), and ship a deployment plan (the final hour). "Study harder" is not a strategy. A system is.