The Last-Minute Exam Survival Guide

I remember in my undergraduate days, three days before my Data Structures exam, I pulled out the stack of lecture notes and realised something awkward: I recognised most of the titles on the front pages, but the notes themselves were almost untouched.

The semester had been full of small emergencies. There were overlapping deadlines, a part‑time job that turned full-time some days and group projects that dragged on for weeks. And I won't hide that procrastination was part of the picture.

The result was obvious: I knew how to wrestle my way through most of the coding assignments, but I couldn't honestly say I understood the ideas behind them. And now the exam was almost here.

At that point, it didn't matter why I was behind. I had a date, a time, and a fixed number of hours before I would sit down in front of the paper. The only useful question became: what can I still do with the time I have left?

"I’ll just read everything" gone wrong

My first instinct was the same one a lot of students have: start from the top and review as far and fast as you can, in other words, "study with no strategy". I printed the slides, opened the textbook, and tried to go chapter by chapter. I highlighted, underlined, and flicked between examples of trees and hash tables.

On paper, it looked like hard work. In reality, I was mostly watching symbols pass in front of my eyes. I could follow the explanation in the moment, but nothing stuck once I turned the page.

The best example of how badly this went was one question on that exam. It asked me to write a function to rebalance a binary search tree. I had seen the diagrams. I remembered the colours and arrows from the slides. But with a blank answer box in front of me, I could not turn that picture in my head into a function I trusted would work.

Around the same time, a friend in Operating Systems made a different mistake with the same outcome. His study group split the material between them: each person prepared notes on one topic and shared them with the others. In the library, it sounded efficient. On the day, he could repeat a rough definition of a mutex, but when he had to reason about concurrent code on the exam, he froze. The summaries were neat, but the understanding wasn’t there.

The lessons learned

When the marks came back, none of this was a surprise. The exam had simply exposed habits that had been there all semester. Looking back, a few things became obvious:

• You can’t "catch up" by consuming more explanations. When time is short, reading and re‑reading is one of the slowest ways to fix gaps. It feels serious, but you learn very little per minute.
• Recognition is not the same as recall. Being able to nod along with a solution is very different from producing one from scratch. Exams mostly test the latter.
• Understanding the style of questions is part of the content. It’s not enough to "know the theory" in the abstract; you need to see how your lecturer turns that theory into actual questions on a paper.
• No last‑minute plan replaces steady work. The most reliable way to do well is still to stay engaged from the first weeks. And this article is about what to do when that hasn’t happened, not a substitute for it.

None of this is particularly original. Most students know this in theory. I did too. The difference came when I stopped treating those ideas as general advice and started designing my last‑minute study around them.

What finally worked

By the time I reached my Database Systems course, I had become better at starting early and keeping up during the semester. Even then, there were terms when other commitments piled up and I found myself behind again.

This time, however, I had learned to approach the problem differently. Instead of asking, "How do I cover everything?" I asked, "If I only fix a few things, which ones will change my grade the most?"

I had gradually developed a simple process that I used whenever time was short and I was under pressure. Not only did it help me get through tough times myself, the same rough method has helped other students I’ve shared it with since.

1. Start from the exam, not the textbook

Looking at it, the book and the notes weren't something I could hope to start and finish, let alone learn, in such a short period of time. So, rather than opening the book, I decided to start with whatever I could find that looked like the actual exam: past papers, sample questions, old assignments. I tried to answer a small set of questions without checking the notes first.

It was uncomfortable, and the mark I would have got on that first "mock" was not something I would show anyone. But within an hour, I knew which topics were likely to matter and where my understanding actually broke down: writing multi‑table queries, reasoning about keys and constraints, and basic normalisation.

2. The compromise: decide what you are willing to miss

It was clear an A was not a realistic goal anymore. So, from there, I made a rough map of the course content and divided it into three groups:

• Core topics: the things that showed up again and again – basic SQL, joins, primary/foreign keys, and 3rd Normal Form. These were the questions that could easily be worth half the paper.
• Important but narrower ideas: material the lecturer had clearly emphasised, such as simple indexing strategies or transaction examples.
• Details I would only touch if there was time: for example, manually estimating the cost of a query plan or reproducing the exact pseudo‑code for a B+‑tree split.

With three days left, I accepted that the third group would probably stay weak. That wasn’t ideal, but it was honest. I would rather be solid on the basics that appear in multiple questions than spend two hours on a detail that might be worth a few marks.

3. The golden rule: read to know, write to learn

As I was becoming more mature, I could recognise fallacies in how I did things, including in studying. One of those was fooling myself into thinking that if I read the textbook or lectures a couple of times over, I had "learned" them. I noticed I understood material much better when I tried to write down, in my own words, what I thought was going on. So I decided to lean on that.

For SQL, that meant picking a handful of small, made‑up tables and writing a few queries by hand, without autocomplete. For normalisation, I took one or two messy examples and walked through them step by step until I could explain why each new schema was an improvement.

Whenever I got stuck, I allowed myself to check a single example, but only long enough to see the piece I was missing. Then I went back to the blank page and started again. It was slow and slightly frustrating, but the next day I could still reproduce the ideas without notes.

4. Planning in 15‑minute blocks

When I was younger, I used to sit down and plan my day in too much detail, packing it with tasks and leaving no room to breathe. Those plans rarely lasted beyond the same day I wrote them, or maybe the next day if I was determined. After a few of those failures, I avoided planning altogether until I was in college and my schedule became more complex.

I started to notice that my time was slipping away in very small pieces, sometimes even less than half an hour. Gradually, I put the fear of "failing at planning" aside and began to set tasks or breaks as small as 15 minutes, simply because I needed that level of control.

It wasn't only the nature of the tasks or the busy schedule that pushed me in this direction. In many cases, I would block out "an afternoon for databases" or "an evening for algorithms", and then watch the time vanish into small decisions – which problem to try, which lecture to rewatch, whether to keep going or to switch topics.

Planning with 15‑minute blocks did two useful things:

• Before I started, I had to decide what I would actually do in each block: "write three queries from last year’s paper", "normalise one schema", "review mistakes from yesterday".
• Once I began, I stopped negotiating with myself. The planner already held the decisions; my job was simply to follow them as well as I could.

Some tasks needed one 15‑minute block, some needed four. Some blocks overran, and some topics still felt messy by the end. But I wasted far less time drifting between topics or re‑organising my notes. For a few days of intense work, that trade‑off was worth it.

If your exam is in 48 hours

If you are reading this close to an exam date, there is no magic sentence here that will turn the situation around. But there are a few concrete steps you can still take:

• Find or build a short set of questions that look like the exam and attempt them without notes, just to see where you stand.
• List the main topics and mark which ones are likely to carry the most marks. Be honest about what you will probably have to leave weaker.
• For each high‑value topic, plan at least one session where you write down on a blank page (writing code, drawing diagrams, or explaining steps in your own words).
• Lay out your remaining waking hours in small blocks, whether you use a notebook, a digital planner, or a printed template. Protect a reasonable amount of breaks and rest.

You may not walk into the exam feeling fully prepared. But you will at least know that you used the time you had on the parts of the course that matter most.