Day 30: Final Review & Cheat Sheet
DAY 30 / 30 · WEEK 4
Goal of the day
Section titled “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
Section titled “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
Section titled “Diagram: the 30-day arc”The complete cheat sheet — every algorithm, every complexity
Section titled “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
Section titled “Interview-day checklist”Not algorithms — logistics and mindset, the things that are easy to forget under pre-interview nerves.
The night before
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.