Software Engineering Flashcards: What to Make, What to Skip, and How to Actually Use Them
I have a confession: I spent two weeks making Anki cards for algorithms before I realized I was doing it completely wrong.
The cards were things like "Explain merge sort." Which is a bad flashcard for two reasons. First, you cannot meaningfully answer it in the few seconds a flashcard expects. Second, even if you could, you have not practiced merge sort — you have practiced reciting a definition of merge sort. Those are not the same skill and they do not transfer to each other.
After a lot of iteration, I figured out what flashcards are actually good for in software engineering, and it is narrower than most people expect.
The honest case for using flashcards
Flashcards work when you need to retrieve a specific fact under pressure. Not understand a concept, not solve a problem — retrieve a fact.
Software engineering has more of those facts than you might think. Not enough to replace problem-solving practice, but enough to make a real difference.
The classic example: you are in an interview and you need to know that inserting into a hash map is O(1) average and O(n) worst case. You probably understand why. But if you have not reviewed it recently, you might hesitate. That hesitation costs you — not because you are wrong, but because it signals uncertainty. A well-maintained deck of complexity facts removes that hesitation.
Same thing for data structure properties. You know roughly how a B-tree works. But do you know off the top of your head why databases use B-trees instead of balanced BSTs? If someone asks you that in a system design interview, you want the answer to come out cleanly, not after a visible two-second search.
Flashcards make those answers automatic. That is their job.
What goes on a card
Be specific and small. One fact per card. If you need more than 15 seconds to answer it, break it into smaller cards or accept that it is not a flashcard — it is a topic to study.
Time and space complexity. This is the clearest win for flashcards in CS. Things like:
- Quicksort average O(n log n), worst O(n²)
- Heapsort always O(n log n), in-place
- Hash map: insert/lookup/delete O(1) average, O(n) worst
- Binary search tree operations O(h) where h is height, O(log n) balanced
- BFS and DFS both O(V + E) on graphs
Most people know these loosely. Flashcards make them precise and instant.
Data structure properties. Not "explain a linked list" but the specific comparative facts that come up in interviews:
- Array vs linked list: random access vs constant-time insertion
- Stack vs queue: LIFO vs FIFO
- Min-heap: root is always minimum, O(log n) insert
- Skip list vs BST: skip list supports concurrent writes more easily
OS and systems concepts. These matter more than most software engineers expect, especially once you move past junior roles.
Process vs thread, mutex vs semaphore, deadlock conditions (CRUD: circular wait, resource holding, no preemption, mutual exclusion), virtual memory basics, what a context switch costs. These fit cleanly onto cards.
Networking. TCP vs UDP: when and why. What the three-way handshake does and why it exists. How DNS resolution works. What happens between typing a URL and seeing a page. The HTTP methods and their semantics. All cardable.
Design patterns. The name, what problem it solves, and a one-sentence structural description. Observer: defines a one-to-many dependency so multiple objects get notified when state changes. Factory: separates object creation from usage. Singleton: one instance, global access point. Do not card the implementation — card the purpose and the trigger: "when you see X, think Y pattern."
Language-specific syntax you personally blank on. This is individual. In Python it might be the difference between deepcopy and copy, or when __slots__ matters. In Java it might be the difference between == and .equals(). Card what you personally forget, not what some list says is important.
What does not go on a card
This is where most software engineering flashcard decks go wrong. People card things that look like facts but are not actually retrievable in isolation.
Algorithm steps. "What are the steps of Dijkstra's algorithm?" is not a flashcard. It is a study topic. If you do not understand Dijkstra's well enough to reason about it, no amount of flashcard review will fix that. You need to work through it, code it, trace through examples. After you truly understand it, you can card the key insight ("greedy, uses a min-heap for the frontier, fails on negative edges") — but the understanding has to come first.
System design concepts. "How would you design Twitter?" cannot be on a card. System design requires synthesis, trade-off reasoning, and asking clarifying questions. You can card individual components — what a CDN does, when to use a message queue, approximate read/write ratios of common systems — but not the design itself.
"Explain X" questions. Anytime your card starts with "explain," you probably need to rethink it. Explaining requires understanding. If you have the understanding, a card can reinforce facts around it. If you do not, the card will teach you to recite a definition, not to actually grasp the thing.
Problems. LeetCode problems are not flashcards. Occasionally you can card the key insight of a problem type ("two-pointer technique works when the array is sorted and you need pairs summing to a target") but not the problem itself.
Building the deck
A few things that actually help.
Make cards after you understand, not before. The workflow is: study the topic, understand it well enough to explain it, then card the specific facts you want to keep sharp. If you card first, you end up reviewing things you do not understand, which is demoralizing and mostly useless.
Keep the front of the card concrete. "What is the worst-case time complexity of quicksort?" beats "Tell me about quicksort." The first has one right answer. The second has a hundred possible answers and you will never quite know if you got it right.
Use cloze cards for related groups. Things like Big-O complexities work well as cloze deletions: "Merge sort is O([...]) time and O([...]) space." This forces you to recall both facts in context without requiring you to write a novel.
Do not import someone else's giant deck without editing it. There are shared Anki decks for CS concepts and interview prep. Some are good. All of them will have cards that are wrong for your needs — too vague, covering things you already know cold, or phrased in a way that does not match how you think. Treat a downloaded deck as a starting point, not a finished product.
How to fit flashcards into interview prep
The mistake most people make is treating flashcards as the primary study method. They are not. For coding interviews, the core work is:
- Solving problems (LeetCode, etc.) with real feedback
- Doing mock system design sessions
- Behavioral prep for your specific stories
Flashcards fit in as a daily maintenance layer. Ten minutes a day keeping your complexity facts sharp, your data structure knowledge fresh, your systems vocabulary precise. They should not take more than that.
A reasonable schedule: 20 minutes of flashcard review in the morning, then the actual problem-solving practice. The cards keep the vocabulary accessible. The practice builds the actual skill.
If you are a student learning CS rather than prepping for interviews, the same principle applies but the ratio shifts. You will spend more time with flashcards because there are more facts to lock in — OS, networks, compilers, databases. Still, the pattern is the same: understand first, card the facts, use spaced repetition to keep them fresh.
A note on apps
Any decent spaced repetition app will work. Anki is the standard because it is free on desktop and has a huge user base, which means shared decks and community resources. The iOS app costs around $25 one-time. If you want something with a cleaner interface and FSRS scheduling by default, Imprimo is worth a look.
The algorithm matters more than people think. FSRS schedules reviews based on your actual recall probability, which means it gives you fewer reviews per card at the same retention level compared to the older SM-2 algorithm. For interview prep with a deadline, that efficiency matters — you have limited time and a lot to cover.
Whatever app you use, review daily. The whole point of spaced repetition is the spacing. A week of skipping and then a long session is worse than ten minutes every day. It does not have to be long. It just has to be consistent.
The short version: flashcards work for the fact layer of software engineering. Time complexities, data structure properties, OS and networking fundamentals, design pattern structures. They do not work for understanding algorithms, practicing problem-solving, or system design. Use them for what they are good at, do not ask them to do more, and keep the deck honest about what belongs in it.