How to Study for Computer Science

Why Reading and Watching Videos Does Not Prepare You for CS Exams

There is a gap unique to computer science that does not exist in most other disciplines: understanding code you are reading and being able to write code from a blank screen are entirely different skills. You can follow a merge sort implementation line by line, understand exactly what each recursive call does, and still be unable to produce one on an exam without reference material.

This is not a knowledge problem. It is a retrieval and execution problem. Watching a YouTube walkthrough of binary search tree insertion trains your brain to recognize the correct answer when it is in front of you. The exam does not put the answer in front of you. It gives you a problem statement and a blank editor.

Every hour you spend reading lecture slides or watching tutorial videos is building recognition, not recall. Recognition is the ability to evaluate a solution that already exists. Recall is the ability to generate one. CS exams test recall. The only way to train recall is to practice generating, which means writing code from scratch, closing your notes, and attempting problems before looking at solutions.

The Three Types of CS Exams and How to Study for Each

Not all CS exams are the same. Conflating them leads to studying the wrong way for the wrong exam.

Coding problem exams ask you to write working code under time pressure, often on a whiteboard, in an online editor, or on paper. These are closest to the LeetCode-style interview format. Preparation must be almost entirely writing code: implement the required algorithms and data structures from scratch repeatedly until you can produce them under any framing of the question.

Written analysis exams test Big O reasoning, proof of correctness, recurrence relations, and algorithmic trade-offs. You are not writing executable code; you are constructing a mathematical argument. These require you to reproduce entire derivations from memory. Reading a Big O proof and understanding it is not sufficient preparation. You need to be able to write it out without notes, the same way a math student must reproduce a proof.

Conceptual short-answer exams are common in survey CS courses, operating systems, networking, and database courses. They ask questions like "what is the difference between a process and a thread" or "explain what happens when a page fault occurs." These respond well to traditional active recall flashcards, but the flashcard prompts should require you to explain the mechanism, not just name it.

How to Study for Programming Assignments and Coding Exams

The rule is simple: implement everything you need to know from a blank file, without copying from existing solutions. This is non-negotiable for developing actual coding ability.

When you are assigned a data structure or algorithm in lecture, implement it the same day without looking at any reference implementation. You will likely get it wrong. That is the point. The debugging process of getting it wrong, identifying where your understanding broke down, and fixing it creates the kind of deep encoding that lecture does not.

Rubber duck debugging is underused as a study method. Before you look anything up, explain your code aloud as if to someone who has never seen it. Walk through what you expect each line to do, then trace through what it actually does. This forces you to locate the gap in your own mental model rather than absorbing someone else's explanation of where you went wrong. The act of articulating the problem builds understanding in a way that reading a stack trace never does.

For coding exams specifically, simulate the exam environment at least once per week. Set a timer, close all documentation, and attempt problems with no assists. Then review after time expires. The discomfort of that practice is exactly what builds the ability to perform under actual exam conditions.

Data Structures and Algorithms: Building Real Intuition

Algorithms and data structures is the course that most determines whether a CS student succeeds long-term, and it is also the course most students study in the least effective way.

Time and space complexity is not something you memorize in a table. It is something you derive. If you can look at a loop structure and derive whether it is O(n), O(n log n), or O(n squared) by reasoning about what the loop does, you do not need to memorize anything. Practice deriving complexity from first principles on every implementation you write.

There is a logical order for building data structure intuition that mirrors how each structure is derived from simpler ones: arrays first (contiguous memory, constant-time access), then linked lists (dynamic size, pointer traversal), then stacks and queues (constrained interfaces built on top of arrays or linked lists), then trees (recursive structure, multiple types including BST, heap, trie), then graphs (generalized trees with cycles), and finally hash tables (the tradeoffs of hashing, collision resolution strategies). Jumping to graphs before understanding trees produces fragile knowledge.

Pattern recognition across problem types matters more than memorization. The question is not "what is the algorithm for this problem?" but "what class of problem is this, and what family of algorithms applies?" Sliding window, two-pointer, divide and conquer, dynamic programming, greedy, BFS/DFS: learn to identify these patterns from problem structure, not from problem title.

Math-Heavy CS Courses: Discrete Math and Theory of Computation

Discrete mathematics and theory of computation follow the rules of math courses, not programming courses. The primary output is a proof, and proofs must be reproduced from scratch to be known.

Reading a proof of the halting problem or a formal language theorem gives you the feeling of understanding. It is not the same as understanding. Understanding a proof means you can reconstruct it without looking at it. That is the test, and it should be the study method: close your notes and write the proof out. Check your version against the original. Fix the gaps. Repeat.

For discrete math, proofs by induction are the most reliably tested and most reliably bombed. The structure is always the same: base case, inductive hypothesis, inductive step. Practice enough induction proofs from scratch that the structure is automatic, and then focus your effort on the algebra in the inductive step, which is where most students fail.

For theory of computation, the constructions (building a DFA, converting an NFA to a DFA, building a Turing machine for a given language) are more important than the theorems. Practice constructing them from problem specifications without looking at examples.

The Night-Before Strategy for CS

The night before a coding exam, do not open the textbook. The textbook is a recognition tool, and you are past the point where recognition helps.

Instead, retrieve. Pick the five or six most important algorithms or data structures from the course and implement each one from memory. Not pseudo-code — actual implementation in the language your exam uses. If you can produce them cleanly, you are ready. If you cannot, the act of attempting and then checking gives you the targeted information you need about where your gaps are.

For written analysis courses, write out two or three proofs from memory and check against your notes. For conceptual courses, quiz yourself using active recall on every term that appeared in lecture.

Do not re-read anything you already understand. The night before is for testing retrieval, not for absorbing new information. Sleep on a consistent schedule. Sleep deprivation degrades the executive function and working memory that coding performance depends on far more than it degrades rote recall.

Group Studying for CS: Pair Programming as Active Recall

Group studying works differently in CS than in other subjects. Passive group study — sitting together while everyone reads their notes — is just as useless for CS as individual passive reading. Active group study can be highly effective.

Pair programming is the most powerful group study method for CS courses. One person writes code while explaining their reasoning aloud; the other listens, asks questions, and catches logical errors. Then you switch. The person explaining is doing the most learning, because explaining forces you to be explicit about steps you would otherwise skip over. The person listening catches bugs and misunderstandings that the coder is too close to see.

The "teach it" method applies here: if you can explain why merge sort has O(n log n) complexity, not just state that it does, you understand it. If your explanation breaks down when your study partner asks a follow-up question, you have found a gap to fix before the exam. Set up sessions where each person takes turns explaining a topic from scratch and the group asks questions designed to probe edge cases and exceptions.

Frequently Asked Questions