Interviews on

Lesson 40: Mock Interview Strategy — The 45-minute framework for any problem

Sun, 01 Mar 2026 00:00:00 +0000

I have had interviews where I solved the problem correctly and still got rejected. I have also had interviews where I struggled significantly with the solution but received strong positive feedback. The difference was not the code — it was everything around the code. How I communicated, how I managed time, how I responded when I got stuck, and whether the interviewer felt like they had seen how I actually think.

Lesson 39: Hard Composites — When one pattern isn't enough

Sun, 15 Feb 2026 00:00:00 +0000

There is a class of interview problem designed specifically to differentiate senior candidates. These are not problems where knowing one pattern is enough — they require you to recognize that two or three patterns need to compose, figure out the seam between them, and implement the composition cleanly under pressure. I call them hard composites.

The candidates who struggle here usually know the individual patterns. The gap is the synthesis. They apply binary search but miss that the search space itself requires a merge step. They build the trie but miss that the relationships between words encode a graph that needs topological sort. Practice the composites explicitly, not just their constituent patterns.

Lesson 38: Design Problems — Build it from scratch in 30 minutes

Tue, 03 Feb 2026 00:00:00 +0000

Design problems in coding interviews are different from system design rounds. You are not sketching architecture at a whiteboard — you are implementing a concrete data structure from scratch, live, in 30 to 45 minutes. The interviewer cares about both correctness and your choices of underlying data structures. “Just use a map” is never a complete answer.

I find these problems particularly satisfying because the solutions are compact. Once you see the underlying pattern — that almost every caching and feed problem requires a hash map layered on top of an ordered structure — the implementations become variations on a theme.

Lesson 37: Concurrency Problems — The questions Google loves

Sun, 18 Jan 2026 00:00:00 +0000

Concurrency problems are the ones where an interviewer can tell immediately whether you actually understand concurrency or have just memorized solutions. They are also the problems where Go shines brightest — goroutines and channels are so expressive for synchronization that solutions which require dense mutex orchestration in Java become almost self-documenting in Go.

Google, in particular, loves these. I have heard this pattern described by multiple engineers who have been through their interview loops: “expect at least one problem where you need to coordinate goroutines.” The underlying skill being tested is not just “can you prevent a race condition” — it is “do you understand which primitives to reach for, and can you reason about your solution’s correctness?”

Lesson 36: Intervals — Sort by start, merge by end

Mon, 05 Jan 2026 00:00:00 +0000

Interval problems show up everywhere — in calendar APIs, in resource scheduling, in genomics, in timeline visualizations. In interviews they appear in a small number of canonical forms, and every form reduces to the same underlying operation: sort by start time, then sweep left to right making decisions based on where the current interval’s end overlaps with the next interval’s start.

I have seen engineers panic at interval problems because the cases feel fiddly. Overlapping but not containing. Contained entirely. Adjacent but not touching. Once you drill the sort-and-sweep template into muscle memory, you handle all the cases in a single pass without tracking them explicitly.

Lesson 35: Greedy — Local optimal leads to global optimal (sometimes)

Tue, 23 Dec 2025 00:00:00 +0000

Greedy algorithms have a brutal failure mode in interviews: the solution looks obvious, you implement it in fifteen minutes, and then the interviewer asks “does this always work?” and you have no good answer. I have been on both sides of that question. Greedy is powerful when the problem has the right structure, and dangerously wrong when it does not.

The discipline is learning to tell the difference. Most greedy interview problems are structured so that a correct greedy choice exists — the challenge is identifying what that choice is and, if asked, arguing why locally optimal decisions accumulate to a globally optimal result.

Lesson 34: Backtracking — Try everything, undo what doesn't work

Thu, 11 Dec 2025 00:00:00 +0000

Backtracking scared me for a long time. The problems looked like they needed some clever mathematical insight — some observation that would magically reduce the search space. Then I realized the actual technique is almost mechanical: build a candidate solution incrementally, check constraints at each step, and undo your last choice if the current path cannot lead anywhere valid. That’s it. The art is in recognizing when to prune.

Every backtracking solution I have ever written follows the same skeleton. Once that skeleton is internalized, the remaining work is problem-specific constraint checking. The code almost writes itself.

Lesson 33: Trie — When you need prefix matching

Wed, 26 Nov 2025 00:00:00 +0000

Tries showed up in a Google interview I did early in my career. The problem was autocomplete. I started sketching a hash map of prefixes to word lists and immediately knew something was wrong — the interviewer was watching too patiently. The correct structure, the one that makes the solution feel inevitable, is a trie. It organizes words so that every prefix lookup is just a traversal of shared nodes, and I had been fighting to reconstruct that structure from scratch.

Lesson 32: Heap Patterns — Keep the top K without sorting everything

Tue, 11 Nov 2025 00:00:00 +0000

The first time I saw a “find the K largest elements” problem in an interview, I sorted the array and returned the last K. Correct answer, wrong approach. Sorting costs O(n log n). A heap does it in O(n log K). When n is a billion and K is ten, that difference matters enormously — and the interviewer knows it.

Heaps feel mystical until you internalize one thing: a heap is not a sorted array. It is a partially ordered tree that guarantees one thing — you can get the minimum (or maximum) element in O(1) and remove it in O(log n). That partial ordering is enough to solve an entire class of problems that would otherwise require full sorting.

Lesson 31: Monotonic Stack — The next greater element trick

Thu, 30 Oct 2025 00:00:00 +0000

I used to brute-force “next greater element” problems. Nested loops, O(n²), and a silent prayer that the input was small. Then a senior engineer at a Google mock interview drew me a picture of a stack where elements got popped the moment something bigger walked in, and the pattern clicked instantly. The monotonic stack is one of those techniques that, once you see it, you wonder how you ever missed it.

Lesson 30: Bitmask DP — When the state is a set

Fri, 17 Oct 2025 00:00:00 +0000

Every DP pattern we’ve covered has kept the state manageable: an index, a remaining budget, a mode. Bitmask DP enters the picture when the state is a subset of elements — specifically, which elements from a small set have been included or visited so far.

The representation is elegant: a bitmask of n bits, where bit i is 1 if element i is in the current subset and 0 otherwise. With n = 20, there are 2²⁰ ≈ 1 million possible subsets. That’s the practical ceiling for bitmask DP — you’ll see n ≤ 20 in problem constraints, and that’s the signal.

Lesson 29: State Machine DP — Track what state you're in

Sat, 04 Oct 2025 00:00:00 +0000

Most DP problems have a clean one-dimensional state: position in an array, remaining capacity, current index. State machine DP adds another dimension that isn’t just a number — it’s a mode or status that your system is in. “Am I currently holding a stock? Am I in a cooldown period? Which color did I just paint the last house?”

The stock trading problems are the canonical example. LeetCode has an entire series of them (I, II, III, IV, with Cooldown, with Transaction Fee) that all share the same structure but add constraints one by one. Solving them all with the same mental framework is satisfying once the state machine clicks.

Lesson 28: Interval DP — Optimal strategy between boundaries

Fri, 19 Sep 2025 00:00:00 +0000

Interval DP is the pattern that solves problems where you need to find the optimal way to process a contiguous segment, and the answer depends on how you choose to “split” or “last-process” within that segment. The classic examples — Burst Balloons, Matrix Chain Multiplication, Optimal BST — all share the same skeleton: try every possible “last operation” position k within [i, j], and combine the subproblems for [i, k] and [k, j].

Lesson 27: Knapsack Patterns — Pick or skip, that's the whole pattern

Fri, 05 Sep 2025 00:00:00 +0000

Knapsack is one of those patterns that shows up in disguise constantly. You’ll see problems framed as “partition this array,” “find a subset with sum X,” “assign +/- signs to get target T” — and underneath each one is the same fundamental structure: for each item, decide whether to include it or exclude it.

The standard 0/1 Knapsack is the reference problem. Every variant is a modification of it: different objective functions (count instead of max value), different constraints (exact sum instead of capacity), different item usage rules (unbounded instead of once). Once you internalize the base pattern, the variants fall into place.

Lesson 26: DP on Trees — Post-order traversal meets memoization

Wed, 20 Aug 2025 00:00:00 +0000

Tree DP is the pattern that catches people by surprise. You’ve been thinking of DP as filling a 1D or 2D table from left to right — a sequential, iterative process. Trees are recursive by nature. The “table” is implicit in the call stack.

The key insight: tree DP is just post-order traversal where each node computes its answer from its children’s answers. There’s no explicit table. The memoization (if you need it) is keyed by node pointer. The bottom-up order is inherently satisfied because post-order visits children before parents.

Lesson 25: DP on Strings — Palindromes and partitions

Sat, 09 Aug 2025 00:00:00 +0000

String DP has its own flavor that’s distinct from the two-string comparison problems of the last lesson. Here, the state is typically a single string, but the subproblem is about a range within that string: “what’s the answer for the substring s[i..j]?” That’s interval DP applied to strings, and palindromes are its most natural setting.

The tricky part with palindrome problems is that you can approach them from the outside in (is s[i..j] a palindrome?) or the inside out (expand from a center). DP works from the outside in: small intervals first, then build up to larger ones. The expansion approach is often faster in practice but DP is more general and extends to partition problems naturally.

Lesson 24: 2D DP Advanced — String comparison is always 2D DP

Thu, 24 Jul 2025 00:00:00 +0000

Edit Distance from the previous lesson is the template for a whole family of problems. Any time you’re comparing two strings — finding common parts, matching patterns, counting transformations — you’re drawing a 2D table where one string indexes the rows and the other indexes the columns.

The structure is always the same: dp[i][j] answers a question about the first i characters of one string and the first j characters of the other. The recurrence depends on whether the current characters match and what operations are allowed.

Lesson 23: 2D DP Basics — Two dimensions, one table

Sun, 13 Jul 2025 00:00:00 +0000

1D DP was a single row — you filled it left to right and you were done. 2D DP extends that to a full table. You fill it row by row, and each cell depends on cells above it, to its left, or diagonally above-left. The shape of that dependency is the shape of the problem.

I find 2D DP more intuitive than 1D once I got comfortable with the table visualization. Unique Paths is a perfect first problem because you can literally draw the grid and fill it in by hand in 30 seconds. Edit Distance is the crown jewel — once you understand why the three transitions correspond to the three edit operations, you’ll never forget the recurrence.

Lesson 22: 1D DP Advanced — When the state space gets interesting

Fri, 27 Jun 2025 00:00:00 +0000

Climbing Stairs and House Robber have a comfortable property: dp[i] depends on just the previous one or two positions. Each step you take looks back a fixed distance. These are the training wheels problems.

Advanced 1D DP breaks that comfort. Word Break needs to look back up to the entire string. LIS needs to look back at every prior element. Coin Change loops over all denominations at every position. The look-back window is variable, sometimes unbounded. The dp array is still 1D — but you need a loop inside a loop.

Lesson 21: 1D DP Basics — If you can solve it recursively, you can DP it

Fri, 06 Jun 2025 00:00:00 +0000

Every time I bombed a DP problem in a mock interview, the pattern was the same: I stared at the problem, thought “this looks like DP,” then froze because I couldn’t immediately write the recurrence. The fix wasn’t to memorize more recurrences. The fix was to stop trying to think bottom-up first.

Here’s the approach that finally clicked: write the recursive solution first. Get it working. Then ask: “which subproblems am I solving multiple times?” Memoize those. Then, if you want to be clean about it, flip it into a bottom-up table. By the time you hit the bottom-up version, the recurrence is already obvious because you derived it from your own recursive code.

Interview Patterns L20: Shortest Path — When edges have weights

Sat, 17 May 2025 00:00:00 +0000

In L16, I explained why BFS solves shortest path problems in unweighted graphs — every edge costs the same, so distance equals hop count, and BFS naturally explores in order of increasing hops. But the moment edges have different weights, BFS breaks. A path with two heavy edges can be longer than a path with ten light ones.

This is the lesson where we graduate to weighted shortest path. Two algorithms matter most for interviews: Dijkstra’s (greedy, non-negative weights) and Bellman-Ford (dynamic programming, handles negative weights). A third problem shows a modified Dijkstra on a 2D grid. Understanding when to use each — and why the other would be wrong — is what separates candidates who have memorized code from candidates who actually understand the algorithms.

Interview Patterns L19: Union Find — Who belongs to whom?

Wed, 30 Apr 2025 00:00:00 +0000

Union Find is one of those data structures that most people never implement until they need it in an interview, and then they discover it is both elegant and surprisingly short. The core idea is deceptively simple: maintain a “parent” array where each element points to its group’s representative. Two operations — Find (who is the root of this group?) and Union (merge two groups) — are all you need.

Interview Patterns L18: Topological Sort — Order tasks with dependencies

Mon, 14 Apr 2025 00:00:00 +0000

Topological sort comes up whenever there is an ordering constraint — “A must happen before B,” “module X depends on module Y,” “this course is a prerequisite for that one.” The algorithm answers: given a directed acyclic graph (DAG) of dependencies, produce a linear ordering of all nodes such that every node appears after all its predecessors.

The word “topological” makes it sound academic. In practice, it is one of the most industrially relevant algorithms: build systems, package managers, spreadsheet recalculation engines, compiler dependency resolution, task schedulers — they all use topological sort or something equivalent. Interviewers ask it because it tests whether you can model real-world dependency problems as graphs and then solve them correctly.

Interview Patterns L17: Graph DFS — Explore everything, mark what you've seen

Mon, 24 Mar 2025 00:00:00 +0000

Graph DFS is the tool you reach for when you need to explore every reachable node, not just the closest ones. Unlike BFS, which expands in rings of increasing distance, DFS commits to one direction until it cannot go further, then backtracks. This makes it naturally suited for problems where you need to visit entire connected regions, detect cycles, or trace paths between specific source and destination sets.

The three problems in this lesson each probe a different dimension of graph DFS. Cloning a graph tests your ability to handle shared references while building a new structure. Pacific Atlantic Water Flow introduces the reverse-DFS technique — instead of asking “where can this water flow?”, you ask “which cells can reach each ocean?” Course Schedule uses DFS to detect cycles, the canonical prerequisite for topological ordering. Together they cover the non-trivial uses of graph DFS that come up in senior engineering interviews.

Interview Patterns L16: Graph BFS — Shortest path in unweighted graphs

Fri, 07 Mar 2025 00:00:00 +0000

The moment someone says “shortest path” in an interview, I mentally split the problem into two cases: weighted or unweighted? If unweighted — every edge costs the same, every step is distance 1 — BFS gives the shortest path guarantee for free. No Dijkstra needed. BFS explores nodes in order of increasing distance from the source, so the first time you reach a destination, that is definitionally the shortest path.

Interview Patterns L15: Tree BFS Patterns — Level by level reveals structure

Fri, 21 Feb 2025 00:00:00 +0000

Level by level. That phrase shows up in maybe a third of binary tree interview problems, sometimes explicitly and sometimes disguised. “What would you see from the right side?” Level by level. “What is the minimum number of steps from root to a leaf?” Level by level. “Connect each node to its right neighbor on the same level?” Level by level.

BFS on trees feels simpler than BFS on graphs because trees have no cycles and no visited-set bookkeeping. But the interesting problems are not about the traversal itself — they are about what you do with the level structure that BFS naturally exposes. In this lesson, I focus on three problems that are each a variation on one theme: level order traversal plus one clever twist per problem.

Interview Patterns L14: Tree DFS Patterns — Every path question is DFS

Thu, 30 Jan 2025 00:00:00 +0000

If a binary tree problem asks anything about paths — longest, shortest, sum along a path, common ancestor between two nodes — the solution is almost certainly DFS. Not because DFS is the only way, but because path problems require you to propagate information up from leaves to ancestors, and that is exactly what post-order DFS does. You compute the answer for children before combining it for the parent.

What I find interesting about this cluster of problems is how they reveal a single reusable DFS skeleton. Once you internalize the pattern — recurse left, recurse right, combine and return — you can adapt it to maximum depth, path sum, diameter, and LCA with only surface-level changes. The thinking cost drops dramatically once you stop treating each problem as novel and start asking “what do I return from each recursive call, and how do I combine it?”

Interview Patterns L13: Tree Construction — Build trees from traversal arrays

Thu, 16 Jan 2025 00:00:00 +0000

Construction problems break the mold. Most tree problems ask you to read a tree and return something — a traversal, a value, a boolean. Construction problems ask you to create a tree from some compact representation. That reversal in direction exposes a different set of thinking skills: can you reason backwards from output to structure? Can you identify what information each traversal encoding uniquely determines?

I think of tree construction as a test of how well you understand what information each traversal preserves and destroys. Inorder alone cannot reconstruct a tree. Preorder alone cannot either. But together they contain exactly enough information. Serialize/deserialize is a different angle: design your own encoding so reconstruction is unambiguous. Both problems show up at Google, Meta, and Amazon with surprising regularity.

Interview Patterns L12: BST Operations — Sorted order hides in every BST

Sun, 29 Dec 2024 00:00:00 +0000

BST problems are deceptively simple on the surface. The property is easy to state: every node’s left subtree contains only values less than it, every right subtree contains only values greater. You have known this since your data structures course. But FAANG interviewers do not ask you to recite the definition — they probe the edge cases, the constraints that cascade from parent to child rather than just between a node and its immediate children, and the elegant iterator pattern that wraps inorder traversal in an on-demand API.

Interview Patterns L11: Binary Tree Traversal — Four ways to walk a tree, four different answers

Tue, 17 Dec 2024 00:00:00 +0000

The moment an interviewer draws a binary tree on the whiteboard, a clock starts. They are not just testing whether you know what inorder means. They are watching how you think about state, iteration, and the relationship between recursive and iterative logic. Four traversal orders — preorder, inorder, postorder, level order — each reveals something different about the tree. Knowing which one to reach for, and being able to implement it iteratively without hesitation, is what separates candidates who get offers from candidates who get “we’ll be in touch.”

Lesson 10: Math Patterns — When the Answer Is Math, Not Code

Mon, 25 Nov 2024 00:00:00 +0000

Some interview problems look like they need a data structure or a clever algorithm, but the answer is actually just math. I’ve watched candidates build hash maps and simulate processes for problems that have elegant O(1) or O(log n) solutions grounded in number theory or geometric reasoning. When I encountered Happy Number for the first time, I tried to detect cycles with a hash set — which works, but the Floyd’s cycle detection approach (same one as linked list cycle detection) is what separates a good answer from a great one.

Lesson 5: Design Twitter/X — Tweet fanout, timeline ranking, trending topics at 500M users

Thu, 14 Nov 2024 00:00:00 +0000

Twitter is the classic system design problem for good reason. It looks like a glorified blog until you start pulling on the threads: how does a tweet from a user with 100 million followers appear in every follower’s timeline within seconds? How do you rank timelines without reading millions of tweets per request? How do you identify trending topics across 500 million users in near real-time? Each of these is a genuinely hard problem, and they interact in non-obvious ways.

Lesson 3: Your Story — Connecting your career narrative to the role

Sat, 09 Nov 2024 00:00:00 +0000

Almost every interview starts the same way: “So, tell me about yourself.” And almost every engineer I’ve talked to hates this question. Not because they don’t know themselves, but because it feels formless. You could say anything. You could say everything. What are they actually asking?

What they’re asking is: give me a thesis statement for why you’re sitting in this chair. Not a resume recitation. Not a biography. A thread that connects where you’ve been to why this job is the logical next step. That thread is your career narrative.

Lesson 9: Bit Manipulation — The Trick Questions That Test Fundamentals

Thu, 07 Nov 2024 00:00:00 +0000

Bit manipulation problems have a reputation for being tricks — the kind of problem where you either know the one-liner or you don’t, and if you don’t, no amount of reasoning will get you there. That’s mostly false. The problems in this lesson have elegant solutions, but those solutions come from understanding a small set of bitwise properties and applying them deliberately. I’ve seen candidates ace these problems in interviews not because they memorized the answer, but because they reasoned through the bit properties in real time.

Lesson 8: Sorting in Interviews — Can You Do Better Than O(n log n)?

Wed, 09 Oct 2024 00:00:00 +0000

Most candidates treat sorting as a black box — call sort.Ints and move on. That works until an interviewer says “can you do this without sorting?” or “implement this yourself” or “what’s the worst-case time?” At that point, not understanding sorting costs you the offer.

I don’t mean you need to memorize every sorting algorithm. You need three things: understand merge sort well enough to implement it (divide-and-conquer is a pattern you’ll use in other contexts); know QuickSelect for kth-element problems (it’s O(n) average and comes up constantly); and know when sorting is all you need and when the comparison lower bound of O(n log n) is a limit you can break. This lesson teaches all three.

Lesson 4: Design WhatsApp — End-to-end encryption, message delivery guarantees, presence

Sat, 14 Sep 2024 00:00:00 +0000

WhatsApp is deceptively simple from a user perspective: you send a message, it arrives. But building a messaging system that handles 100 billion messages per day with end-to-end encryption, reliable delivery semantics, and real-time presence for 2 billion users is a genuinely hard engineering problem. I find this problem particularly instructive because it forces you to confront three things simultaneously: cryptographic key management, message delivery guarantees, and the cost of maintaining online/offline state at massive scale.

Lesson 7: Recursion — Trust the Recursion, Define the Base Case

Sat, 07 Sep 2024 00:00:00 +0000

Recursion trips people up not because the concept is hard, but because they try to trace through it. “If I call f(3), then f(3) calls f(2), which calls f(1)…” and then they lose the thread. I used to do this. My interviewer at a Series B startup once watched me spend three minutes trying to mentally simulate a recursive call stack for a problem that had a two-line solution once I stopped simulating and started trusting.

Lesson 2: Leadership and Conflict — The questions that decide senior vs mid-level

Wed, 14 Aug 2024 00:00:00 +0000

There’s a specific moment in every senior-level interview loop where the conversation shifts. The system design round wraps up, the coding is done, and then an interviewer leans back and asks something like: “Tell me about a time you had to push back on a product decision you thought was wrong.” Or: “Describe a situation where you disagreed with your tech lead and how you handled it.”

These are not softballs. For companies hiring at senior or staff level, behavioral questions about leadership and conflict are often the deciding signal. Everyone who makes it to that round can code. Not everyone can navigate the organizational and interpersonal dynamics of a senior role. These questions are trying to separate the two.

Lesson 3: Design Google Docs — Real-time collaboration, OT vs CRDT, conflict resolution

Mon, 15 Jul 2024 00:00:00 +0000

Google Docs is the problem I recommend to every engineer who thinks they understand distributed systems. The surface looks trivial: multiple users editing a document simultaneously. The depth is staggering. When two users type at the same position in a document at the same millisecond, what does each user see? How do you converge on a consistent state without a central lock? How do you preserve the intention behind each edit, not just the characters?

Lesson 6: Linked Lists — Pointer Manipulation Is the Real Test

Fri, 31 May 2024 00:00:00 +0000

Linked lists are where candidates reveal whether they actually understand pointers. You can read a hundred tutorials on reversing a linked list, but the first time you try to code it under pressure, you will likely lose a node, corrupt the list, or write an infinite loop. I know because it happened to me in a mock interview. The problem itself is not hard. The pointer mechanics are.

This lesson is about building the mental model that makes pointer operations feel mechanical rather than scary. Meta asks linked list questions constantly — their systems rely heavily on custom allocators and cache implementations, and linked lists are the natural test vehicle. Amazon uses the LRU cache variant to test both data structure design and implementation discipline.

Lesson 2: Design Uber — Real-time matching, geospatial indexing, surge pricing

Sat, 25 May 2024 00:00:00 +0000

Uber is one of the most instructive system design problems because it forces you to think about real-time data pipelines, spatial indexing, and latency-sensitive matching algorithms all at once. I spent a significant amount of time studying this problem specifically because the geospatial angle is something most candidates gloss over. They say “use a database with location queries” and move on. But at Uber’s scale — 5 million trips per day, hundreds of thousands of concurrent drivers and riders — the geospatial indexing strategy is the entire problem.

Lesson 1: The STAR Method — "Tell me about a time you..." and how to actually answer

Fri, 10 May 2024 00:00:00 +0000

I used to dread behavioral interviews. I was confident in system design rounds, reasonably calm under algorithm pressure, but the moment someone said “tell me about a time you disagreed with a technical decision,” I felt my brain empty out completely. I would ramble for two minutes, lose the thread halfway through, and trail off into something like “…so yeah, it worked out eventually.” Not exactly compelling.

The STAR method fixed that — not because it’s magic, but because it gives a structure that stops you from wandering. Situation, Task, Action, Result. Four buckets. Every behavioral answer you’ll ever give fits into them.

Lesson 5: Binary Search — When the Search Space Is Sorted or Monotonic

Thu, 09 May 2024 00:00:00 +0000

Binary search has a reputation as the thing you learned in your first CS course and never thought about deeply again. Then you encounter a rotated array or a capacity-minimization problem in an interview, and suddenly it is not obvious at all. I’ve seen engineers who could recite the textbook implementation fail completely on problems that are, at their core, binary search — because the search space isn’t an array of values, it’s something more abstract.

Lesson 4: Stack — Last In, First Out Solves More Than You Think

Sat, 13 Apr 2024 00:00:00 +0000

The stack is one of those data structures that seems too simple to be interesting — push, pop, peek, done. Then you sit in an interview, stare at a problem about brackets or expression evaluation, and realize you’re reaching for exactly this tool. I’ve seen candidates overcomplicate parenthesis validation with counters and flags when a stack makes it four lines of logic. I’ve also seen the reverse: candidates who knew the stack solution for valid parentheses but couldn’t extend the thinking to a harder variant.

Lesson 1: Design YouTube — Video upload, transcoding, streaming at scale

Tue, 09 Apr 2024 00:00:00 +0000

YouTube serves over 500 hours of video uploaded every minute and delivers billions of views per day. When I first studied this problem seriously, I made the mistake of treating it as a simple “upload file, store it, serve it” exercise. It isn’t. The interesting engineering is in what happens between the moment a creator hits upload and the moment a viewer’s video starts playing seamlessly on a 3G connection in rural India. That gap is where the system design lives.

Lesson 3: Sliding Window — Fixed or Variable, the Window Always Moves Right

Thu, 28 Mar 2024 00:00:00 +0000

Sliding window problems have a tell: the problem asks about a contiguous subarray or substring, and there’s a constraint that makes the brute force obvious but slow. When I was interviewing at a mid-size fintech that fancied itself FAANG-adjacent, I got a stock price problem in my first round. I almost panicked — “is this dynamic programming?” It wasn’t. It was a sliding window in disguise, and once I saw it, the solution wrote itself in about four minutes.

Lesson 2: Two Pointers — When One Pointer Isn't Enough

Thu, 14 Mar 2024 00:00:00 +0000

One of my early interview mistakes was throwing a hash map at every array problem. It works a surprising amount of the time, but there’s a whole class of problems where you don’t need extra space at all — where the structure of the input lets two indices do the work together. Two pointers is that technique, and once you see it, you cannot unsee it.

The pattern shows up at every company. Amazon loves it for stream-processing problems. Google uses it for geometry and partition questions. Meta favors it in string validation and deduplication. Three Sum alone has appeared in more on-site rounds than I can count.

Lesson 1: Arrays and Hashing — The Pattern Behind 30% of All Interview Questions

Sun, 03 Mar 2024 00:00:00 +0000

When I was preparing for my first round of FAANG interviews, I was overwhelmed. Hundreds of LeetCode problems, dozens of patterns, no clear starting point. Then I noticed something: roughly a third of the medium-difficulty problems I encountered could be cracked with one insight — trading time for space using a hash map. Once I internalized that, arrays and hashing stopped feeling like a category and started feeling like a reflex.