DAY 30 / 30 · WEEK 4
Final Review & Cheat Sheet
Goal of the day
- Compress all 30 days into one scannable reference: every algorithm, its complexity, and the one-line signal that says "use this one."
- Walk away with a practical interview-day checklist — not more algorithms, the logistics and mental checklist for the actual day.
- See your own progress through the course, and know exactly what's left if anything is.
Concept
There's no new algorithm today. Days 1 through 29 built roughly 30 real, working implementations from scratch — every one of them node-verified before it ever reached a page, every diagram checked for the same handful of recurring bugs, every animation traced against the actual code it's demonstrating. That's the entire point of this course: not reading about algorithms, but building and watching each one actually run. Day 30 is compaction, not addition — turning a month of that work into a single page you can review in ten minutes the morning of a real interview.
The two deliverables below are meant to be used differently. The cheat sheet is a lookup table — skim it now, then come back to it later whenever a specific complexity or trigger phrase needs confirming. The interview-day checklist is meant to be read once, close to the actual day, since it's about logistics and mindset rather than material you need to memorize.
Diagram: the 30-day arc
Interactive: your progress
Loading your progress…
—
The complete cheat sheet — every algorithm, every complexity
All 30 days, one table. "Trigger" is the one-line signal from Day 28's recognition process — the phrase or shape that tells you to reach for this specific row.
| Algorithm | Day | Time | Space | Trigger |
|---|---|---|---|---|
| Two Pointer | 4 | O(n) | O(1) | Converge from both ends of a sorted/orderable structure |
| Sliding Window | 5 | O(n) | O(1) – O(k) | Contiguous range with a grow/shrink validity condition |
| Hash Map / Set frequency | 6 | O(n) | O(n) | Need O(1) lookup/count; order doesn't matter |
| Bubble / Insertion Sort | 8 / 8c | O(n) best, O(n²) worst | O(1) | Small or nearly-sorted input, simplicity over speed |
| Selection Sort | 8b | O(n²) always | O(1) | Minimize the number of swaps specifically |
| Recursion (naive) | 9 | often O(2ⁿ) | O(depth) | Problem splits into smaller identical subproblems |
| Merge Sort | 10 | O(n log n) always | O(n) | Guaranteed worst-case time AND stability required |
| Quick Sort | 11 | O(n log n) avg, O(n²) worst | O(log n) | In-place sorting, average-case speed matters most |
| Binary Search — exact match | 12 | O(log n) | O(1) | Sorted array, looking for an exact value |
| Binary Search — boundary / search on answer | 13 | O(log n) or O(n log m) | O(1) | First/last occurrence, or a monotonic predicate |
| Quickselect | 14 | O(n) avg, O(n²) worst | O(1) extra | Kth largest/smallest without fully sorting |
| Linked list insert/delete at known node | 15 / 16 | O(1) | O(1) | O(1) insert/delete needed, no array shifting allowed |
| Fast/Slow Pointers | 16 | O(n) | O(1) | Find the middle, or detect a cycle, in one pass |
| Stack (Valid Parens / Min Stack) | 17 | O(1) per op | O(n) | Most-recent-first (LIFO) matching or undo |
| Queue / Deque (Sliding Window Max) | 18 | O(n) amortized | O(k) | FIFO order, or a monotonic window |
| BFS (tree) | 19 | O(n) | O(n) | Level-order traversal |
| DFS (tree) | 19 | O(n) | O(h) | Full-depth traversal, or backtracking |
| BST search / insert | 20 | O(h) | O(1) iterative | Sorted-order search/insert, or free sorted traversal |
| Iterative inorder BST validate | 21 | O(n) | O(h) | Validate sorted order without recursive min/max bounds |
| Heap insert / extract | 22 | O(log n) | O(n) | Repeated min/max needed from a changing set |
| Graph BFS / DFS | 23 | O(V + E) | O(V) | Nodes connect arbitrarily, not a strict hierarchy |
| BFS shortest path (unweighted) | 24 | O(V + E) | O(V) | Fewest hops/edges between two nodes |
| Topological Sort (Kahn's) | 24 | O(V + E) | O(V) | Order with dependencies; detect a cycle as a side effect |
| DP — sum recurrence (Fibonacci / Climbing Stairs) | 25 | O(n) | O(1) rolling | Count ways, overlapping subproblems, no decision involved |
| DP — max-of-choices (House Robber) | 26 | O(n) | O(1) rolling | Optimization with a constraint, 2 mutually exclusive options |
| DP — unbounded (Coin Change) | 26 | O(amount × options) | O(amount) | Reusable "coins," min/max over every option at each cell |
| Greedy (interval scheduling) | 27 | O(n log n) | O(1) – O(n) | Provably safe locally-optimal choice; sort first |
| Expand Around Center (palindrome) | 29 | O(n²) | O(1) | Longest palindromic substring |
| 2D DP (Longest Common Subsequence) | 29 | O(m × n) | O(m × n) | Compare 2 sequences, subsequence not substring |
| Multi-source BFS | 29 | O(rows × cols) | O(rows × cols) | Distance from several simultaneous starting points |
Interview-day checklist
Not algorithms — logistics and mindset, the things that are easy to forget under pre-interview nerves.
The night before
- Skim the cheat sheet above once. Don't try to learn anything new — if a pattern still feels shaky, review its specific day, but don't cram unfamiliar material the night before.
- Confirm the format: phone screen, virtual whiteboard, take-home, or onsite — each has different logistics worth knowing in advance.
- Get real sleep. Recognizing patterns under time pressure (Day 28/29) is measurably harder when tired — this is not a night to stay up solving one more problem.
The morning of
- Warm up with one Easy problem, untimed — not to learn anything new, just to get your "talk while you code" muscle moving before it matters.
- For remote interviews: test your camera, microphone, and the specific coding environment (CoderPad, HackerRank, shared Google Doc, whatever they use) at least 15 minutes early.
- Have water nearby, and use the restroom before the call — obvious, and still worth writing down, since it's the first thing anyone forgets when nervous.
During each problem
- Clarify the problem and constraints out loud before doing anything else (Day 29's time-budget diagram).
- State a brute-force approach and its complexity, even if you never write it.
- Name the pattern you're reaching for, and why — the reasoning chain from constraint to choice (Day 28) is what's actually being evaluated, not just the final code.
- Narrate briefly while coding — short, present-tense, not a monologue and not silence.
- Trace your code against the given example before declaring it done. If time remains, test an edge case the example doesn't cover.
After each problem
- If you're asked "any questions for me" and you have none prepared, ask about the specific problem — "was there a follow-up you'd normally ask here?" — it's a fair question and shows genuine engagement.
- Whatever happened, however it went, thank the interviewer specifically — interviewing is also work on their end.
Interview corner — what comes after Day 30
- How do you keep these skills sharp after finishing the course? Spaced repetition beats cramming — revisit the cheat sheet on a schedule (weekly, then monthly) rather than once and never again. Pattern recognition specifically decays faster than raw knowledge; the drill from Day 28 is worth repeating periodically with fresh problems.
- What should the next month of practice look like? Pick problems by pattern, not by random difficulty — deliberately practicing 5 sliding-window problems in a row builds recognition speed faster than 5 random problems from 5 different patterns. Mix in a timed mock session (Day 29's format) roughly weekly.
- How do you handle a bad interview or a rejection? Every real candidate has
bad rounds — a single miss rarely reflects overall skill as accurately as it feels like it does
in the moment. Debrief honestly the same way Day 29 asked you to: which phase actually went
wrong (recognition, time management, communication, or a genuine gap in a specific pattern),
and let that — not general anxiety — drive what you practice next.
↳ Common follow-up: "How many interviews before it stops feeling this stressful?" — same answer as Day 29's mock-session question: there's no fixed number, but the discomfort is a rehearsable skill, not a fixed trait, and it does measurably fade with repetition. - What's genuinely different about you after 30 days, versus someone who just read about these patterns? Every algorithm in this course was verified against real test cases before it ever became a page — you've watched each one actually run, not just read a description of how it should behave. That's the gap between recognizing a pattern's name and trusting yourself to implement it correctly under pressure, and it's the entire reason this course insisted on runnable code and traced animations instead of prose explanations alone.
Quiz — final check
1. In one sentence, what actually separates sliding window from two-pointer?
2. Why does merge sort guarantee O(n log n) in the worst case, while quick sort can degrade to O(n²)?
3. Why does an iterative inorder walk with a plain stack correctly validate a BST, with no min/max bounds tracked anywhere?
4. What single property has to hold before a greedy algorithm is safe to trust?
5. In Kahn's algorithm, what does it mean when the final order comes up shorter than the total number of nodes?