Fundamentals 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.

Lesson 5: Debugging in Kubernetes — kubectl tricks that save hours

Tue, 18 Mar 2025 00:00:00 +0000

The most stressful hours of my on-call life have been in Kubernetes clusters where something was wrong but nothing was obviously broken. Pods in Pending for reasons that weren’t clear. Services returning 503s but all pods showing as Running. Memory usage climbing slowly across a fleet for two days before things started dying. Over years of debugging production Kubernetes issues, I’ve accumulated a set of commands and mental models that cut through the noise. This article is that collection.

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.

Lesson 4: Operators and CRDs — Extending Kubernetes with your own resources

Fri, 03 Jan 2025 00:00:00 +0000

I used to manage PostgreSQL on Kubernetes with a collection of shell scripts and Helm hooks. Provisioning a new database instance meant running a script that created a StatefulSet, a Service, a ConfigMap, a Secret, and set up replication. Failover meant manually triggering another script. Backups were a cron job that required careful coordination with the stateful set. Every operational task was a script that a human had to run, remember, and maintain. Then I discovered the Zalando Postgres Operator, and I understood what the Operator pattern is actually for: encoding human operational knowledge into the Kubernetes control plane itself.

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.

Lesson 4: Code Generation — From AST to bytecode or machine code

Fri, 20 Dec 2024 00:00:00 +0000

The tree-walking interpreter in Lesson 3 works, but it has a ceiling. Every time you evaluate an expression, you traverse the AST from scratch. No caching, no precomputed form, no optimization. For a REPL or a small scripting language this is fine. For a production language runtime — something that runs for hours, executes millions of operations — you want a tighter inner loop. That tighter loop is a virtual machine executing bytecode. And the step that produces bytecode from the AST is code generation.

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 4: Recommendation Systems — Collaborative filtering, embeddings, and the cold start problem

Fri, 13 Dec 2024 00:00:00 +0000

Recommendation systems are the most economically consequential ML systems most engineers will ever build. Netflix estimates that its recommendation system saves over a billion dollars per year in avoided cancellations. Amazon’s “customers who bought this also bought” drives a significant fraction of its revenue. Spotify’s Discover Weekly has become a user retention flywheel. The stakes are real, and the engineering is genuinely interesting.

I got deep into recommendation systems when I was working on a content platform that had about 500,000 items and needed to surface relevant content for each user without overwhelming the ranking team with engineering requests. What I found was that the architecture of a production recommender is almost always the same shape, regardless of the domain — and the hardest problem is not the ML, it’s the cold start.

Lesson 3: GraphQL in Go — gqlgen, resolvers, and DataLoader for N+1

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

Go is not the most common language for GraphQL tutorials. Most of the ecosystem documentation assumes you’re working in JavaScript or TypeScript, and a lot of the tooling is designed around Node’s event loop model. But Go is an excellent choice for a GraphQL server — statically typed, fast, and with gqlgen you get one of the cleanest schema-first GraphQL implementations I’ve used in any language.

This lesson is about making it work in production: generating a working server from a schema, implementing resolvers correctly, and fixing the N+1 problem with DataLoader before it shows up in your latency graphs.

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 3: CQRS + Event Sourcing Together — When the combination makes sense

Sun, 24 Nov 2024 00:00:00 +0000

CQRS and event sourcing are often discussed together, presented as a single package, and that conflation is responsible for a lot of unnecessary complexity in codebases that should have stayed simple. I’ve seen teams adopt both because they read a blog post, without being clear on why they needed either. I’ve also seen teams who should have used both and instead built elaborate workarounds that were essentially CQRS and event sourcing with worse ergonomics. The question isn’t “should I use CQRS and event sourcing?” — it’s “do I have the specific problems these patterns solve?”

Lesson 15: CAP Theorem in Practice — What It Actually Means for Your System

Tue, 19 Nov 2024 00:00:00 +0000

CAP theorem is probably the most cited and most misunderstood concept in distributed systems interviews. Candidates memorize “you can only pick two of consistency, availability, and partition tolerance” and then either over-apply it (treating every design decision as a CAP trade-off) or under-apply it (never relating it to actual design choices). The theorem is real and important, but the way it’s usually taught in 30-second summaries strips out the nuance that makes it actually useful. This final lesson clears that up.

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 14: Designing for Failure — Circuit Breakers, Bulkheads, Chaos

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

In distributed systems, failure is not an exceptional case — it’s the default condition. Networks partition. Hard drives fail. Memory fills up. Dependencies have bugs. Every distributed system that’s been running for more than a few years has experienced every kind of failure you can imagine, and many you can’t. The engineers who build resilient systems aren’t smarter than the ones who don’t. They’ve just internalized a single principle: design for when things go wrong, not for when things go right.

Lesson 14: Randomized Algorithms — Reservoir sampling, HyperLogLog, probabilistic counting

Fri, 01 Nov 2024 00:00:00 +0000

There is a class of production problems where exact answers are either impossible or not worth the cost. You want to know approximately how many unique visitors hit your site today. You want to sample 1% of requests for tracing without reading every request into memory first. You want to check if a username is already taken without querying the database on every keystroke.

Randomized algorithms provide exact answers with known probability bounds, or approximate answers with bounded error, using a fraction of the memory or time that exact computation would require. I was skeptical of “probabilistic” algorithms for a long time — it seemed like trading correctness for efficiency. Then I learned what the error bounds actually are. A HyperLogLog cardinality estimate with 1.5% error using 12KB of memory is a better engineering choice than a perfect count using 100MB, for the vast majority of use cases.

Lesson 13: Design a Payment System — Idempotency, Reconciliation, Double-Entry

Mon, 21 Oct 2024 00:00:00 +0000

Payment systems have a property that almost no other software has: the cost of a bug isn’t a bad user experience — it’s a legal liability and a business catastrophe. Charging a customer twice, losing a transfer in a network failure, or crediting the wrong account can result in millions of dollars of loss and destroyed trust. Every other system we’ve covered tolerates a degree of eventual inconsistency. Payment systems, in most cases, do not. This lesson is about building for that level of correctness.

Lesson 13: Cryptographic Primitives — Hashing, HMAC, and never rolling your own

Thu, 17 Oct 2024 00:00:00 +0000

There is a joke in security circles: every developer thinks they can write their own crypto. The punchline is that everyone who has tried has been wrong. Cryptography is the one area of computer science where being 99% correct is the same as being completely wrong. A subtle timing vulnerability, a nonce reuse, or a hash function with the wrong properties can completely destroy a security guarantee that looks solid on paper.

Lesson 3: ConfigMaps and Secrets — Configuration without rebuilding

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

We had a bug where the same Docker image was running in staging and production but behaving differently. I spent an hour diffing the code before I checked the environment variables. The staging pod had CACHE_TTL=60 and the production pod had CACHE_TTL=3600. The image was identical. The behavior was totally different. That kind of environment-specific configuration — the values that shouldn’t be baked into the image — is exactly what ConfigMaps and Secrets are for. But they have subtleties that bite you if you treat them as simple key-value stores.

Lesson 3: Model Serving — Latency, batching, A/B testing in production

Mon, 14 Oct 2024 00:00:00 +0000

Training a model is satisfying. Deploying it to serve real traffic is humbling. I remember the first time I pushed a model to production and watched the p99 latency hover at 800ms on what was supposed to be a “fast” model. The benchmark had shown 12ms inference time. What happened? The benchmark ran the model on pre-loaded batches; production served one request at a time, loaded the model fresh on cold starts, and had no GPU batching. The gap between “the model is accurate” and “the model is fast enough to be useful” is where model serving engineering lives.

Lesson 2: Server-Side WASM — WASI, edge computing, and the universal binary

Fri, 11 Oct 2024 00:00:00 +0000

When most people talk about WebAssembly, they mean the browser. That’s where it started, that’s where the tutorials are, and that’s where most of the public discourse still lives. But the more interesting story for backend engineers is what happens when you take the same sandboxed, portable binary model and apply it on the server.

Server-side WebAssembly — specifically WebAssembly with WASI (the WebAssembly System Interface) — is not a toy. Cloudflare Workers runs WASM. Fastly Compute runs WASM. Fermyon Spin is built on it. The pattern is spreading from edge providers into general-purpose infrastructure. Understanding it now puts you ahead of where most backend engineers are.

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 12: Design a Search Engine — Inverted Index and Ranking

Mon, 07 Oct 2024 00:00:00 +0000

Search is the feature that separates usable products from unusable ones at scale. When your application has thousands of documents, a sequential scan works. At millions, it doesn’t. The difference between a search box that works and one that times out is a data structure invented in the 1960s that every modern search engine still fundamentally relies on: the inverted index. Understanding how it works — and how to build a system around it — is what this lesson is about.

Lesson 3: Paxos and Beyond — When Raft isn't enough

Fri, 04 Oct 2024 00:00:00 +0000

After spending time with Raft, I found myself curious about the algorithm it was designed to replace. Paxos has a reputation: brilliant, correct, nearly impossible to implement correctly, and even harder to extend to practical systems. Leslie Lamport published the original Paxos paper in 1989, got it rejected, submitted a revised version in 1998, and it became the theoretical foundation for a generation of distributed systems. Chubby (Google’s distributed lock service), Zookeeper (the coordination service), and the precursor to Spanner all descended from Paxos thinking. Understanding why Raft was necessary requires understanding what Paxos gets right and where it falls short in practice.

Lesson 12: Compression Basics — Why gzip works and entropy matters

Thu, 03 Oct 2024 00:00:00 +0000

Every senior engineer I know makes compression decisions regularly: should this API response be gzip-compressed? Should logs be stored compressed? What compression level? Which algorithm? I made these decisions for years based on “gzip is standard, use it” without understanding why it worked or when something else might be better.

Understanding the fundamentals of how compression works — entropy, Huffman coding, and LZ77 — changed how I think about data formats, wire protocols, and storage costs. It also helped me understand why some data compresses well and some data does not, which is critical for capacity planning.

Lesson 3: AST and Evaluation — Walking the tree to compute results

Thu, 03 Oct 2024 00:00:00 +0000

After the lexer and parser, we have a tree. A beautiful, hierarchical, unambiguous representation of the program. Now we need to make it do something. The simplest way to execute a program from its AST is to walk the tree recursively and compute results as you go. No intermediate representation, no bytecode, no machine code — just a recursive function that pattern-matches on node types and returns values.

This is a tree-walking interpreter. It is not the fastest approach (we cover bytecode and code generation in Lesson 4), but it is the most direct. Many production language implementations started here — and some, like early Ruby and Python, stayed here for a long time.

Lesson 11: Design a Notification System — Push vs Pull, Priority, Dedup

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

Notifications are the feature that can make or break user retention — and also destroy it. Done right, they bring users back at exactly the right moment. Done wrong, they’re spam that drives uninstalls. The system design challenge isn’t just the technical plumbing (though that’s interesting). It’s building infrastructure that’s fast for critical alerts, reliable for important messages, and smart enough to not overwhelm users with low-priority noise.

The Core Concept

A notification system has to handle multiple channels with wildly different characteristics:

Lesson 11: String Algorithms — KMP, Rabin-Karp, and why regex can be slow

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

String processing sits at the foundation of almost every production system. Log parsing, protocol parsing, search, validation, templating — it all comes down to finding and transforming patterns in text. Most of the time, strings.Contains or a simple loop is fast enough. But when you are processing millions of log lines per second, or running user-supplied patterns against untrusted input, or implementing a search feature that needs to handle long documents, naive string matching becomes a bottleneck or a security hole.

Lesson 12: Ring Buffers — Fixed-size queues for real-time systems

Mon, 16 Sep 2024 00:00:00 +0000

The ring buffer is the data structure that makes real-time systems possible. Audio processing, network packet capture, kernel I/O buffers, metrics collection — anywhere you have a producer and a consumer that need to exchange data with zero allocation and bounded latency, you’ll find a ring buffer.

It’s also one of the most elegant structures in systems programming: a fixed-size array, two indices, and one invariant. Let me show you how it works and why it appears everywhere from Linux kernel drivers to Disruptor (the LMAX exchange’s million-transactions-per-second queue).

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 2: Projections and Read Models — Build any view from your event stream

Fri, 13 Sep 2024 00:00:00 +0000

After I shipped the event-sourced account system, the first question from the product team was: “Can we have a page that shows all accounts that have been dormant for more than 90 days?” In a traditional system, this is a query: SELECT * FROM accounts WHERE last_activity < NOW() - INTERVAL '90 days'. In event sourcing, there’s no last_activity column — there’s an event stream. My first instinct was to query the event store directly, find the latest event per stream, and filter. It worked. Then they asked for the top 100 accounts by balance. Then active accounts by geography. Then a real-time dashboard with all of the above simultaneously. Querying the event store for each of these is either very slow or very complex. The answer is projections — pre-computed read models built from your event streams.

Lesson 10: Vacuum and Bloat — Why Postgres Tables Grow

Mon, 09 Sep 2024 00:00:00 +0000

I watched a Postgres instance run out of disk space on a 500 GB SSD. The database had 50 GB of actual data. The other 450 GB was table bloat — dead row versions from MVCC that vacuum had failed to clean up. A batch job had been running long-running transactions for weeks, holding a transaction horizon that prevented vacuum from reclaiming anything. By the time we noticed, the disk was nearly full and autovacuum was struggling to catch up. Understanding why this happens — and how to prevent it — is one of the most important operational skills for running Postgres in production.

Lesson 2: Schema Design — Types, queries, mutations, and subscriptions

Sun, 08 Sep 2024 00:00:00 +0000

The schema is the most important artifact in any GraphQL API. It is simultaneously the contract between your client and server, the documentation for every engineer who works with the API, and the boundary that forces you to think clearly about your domain before writing any implementation code. A well-designed schema makes everything easier. A poorly designed schema compounds every mistake downstream.

I’ve seen both. The experience of inheriting a badly designed GraphQL schema — full of inconsistent naming, misused types, nullable fields everywhere because someone wasn’t sure — is one of the more persistent forms of technical debt I’ve encountered. Unlike a poorly written function, a bad schema is public-facing. You can’t just refactor it; you have to version and deprecate carefully.

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 10: Design a News Feed — Fan-out on Write vs Read

Fri, 06 Sep 2024 00:00:00 +0000

The news feed is the product feature that defines social media. Every time you open Instagram or Twitter, you see a personalized, ranked, real-time stream of content from people you follow. Behind that deceptively simple UI is one of the hardest distributed systems problems in consumer tech: how do you compute a personalized feed for hundreds of millions of users, where any piece of content needs to appear in potentially millions of feeds, within seconds of being posted?

Lesson 11: Skip Lists — How Redis sorted sets work

Tue, 03 Sep 2024 00:00:00 +0000

Redis chose skip lists for its sorted set implementation, and that choice is more interesting than it first appears. When you have ZADD, ZRANGE, and ZRANK all needing to run at O(log n), you might reach for a balanced BST. But Redis chose a probabilistic alternative that’s simpler to implement, easier to reason about in concurrent contexts, and performs comparably in practice.

Understanding skip lists taught me something important about engineering tradeoffs: sometimes “good enough with simpler code” beats “optimal but complex.”

Lesson 10: Backtracking — Constraint satisfaction and config generation

Mon, 02 Sep 2024 00:00:00 +0000

Backtracking is the algorithmic equivalent of “try everything, but be smart about giving up early.” It is a systematic way to explore a search space where you build a solution incrementally and abandon partial solutions as soon as you detect they cannot possibly lead to a valid result.

I first encountered backtracking outside of textbooks when building a scheduling system that needed to assign employees to shifts while respecting availability constraints, skill requirements, and labor regulations. The brute force approach — enumerate all possible assignments — was computationally equivalent to exploring all permutations, which was 20! for 20 employees. Backtracking with constraint pruning reduced the search space by several orders of magnitude.

Lesson 9: Partitioning — Range, Hash, List and When Each Helps

Sat, 24 Aug 2024 00:00:00 +0000

I have worked with a few systems that had grown their main tables to 500 million rows or more. At that scale, even well-indexed queries start slowing down — not because the indexes are wrong, but because the index itself becomes large and the buffer cache can only hold so many pages. Vacuum struggles to keep up. EXPLAIN output looks fine but queries still feel sluggish. Partitioning is the architectural solution to this class of problem: instead of one big table, you have many smaller tables that look like one from the application’s perspective.

Lesson 8: Technical Debt — When to pay, when to live with it

Fri, 23 Aug 2024 00:00:00 +0000

The term “technical debt” gets used to mean everything from “this code is a mess” to “we made a pragmatic shortcut we need to revisit” to “this system has grown organically and nobody understands it anymore.” These are different problems requiring different responses. Treating all technical debt as something that must be paid now, or all of it as something acceptable to defer indefinitely — both lead to bad outcomes. The skill is knowing which debt to address, when, and how.

Lesson 9: Design a Chat System — WebSocket, Presence, Message Ordering

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

Building a chat system is the interview problem that catches people on protocol fundamentals. HTTP is a request-response protocol — the client asks, the server answers, and then the connection is idle. For chat, the server needs to push messages to clients the moment they arrive. This inversion of the HTTP model is what makes chat hard, and it’s what drives the entire architecture.

The Core Concept

Why HTTP polling doesn’t work at scale

Lesson 10: Bloom Filters — Probably yes, definitely no

Mon, 19 Aug 2024 00:00:00 +0000

There’s a beautiful data structure that will tell you one of two things: “definitely not in the set” or “probably in the set.” That asymmetry — where false negatives are impossible but false positives are allowed — turns out to be useful in an enormous number of production scenarios.

Bloom filters use a fraction of the memory of a hash set, and the math behind their false positive rate is surprisingly elegant. Once you understand them, you’ll see why databases, CDNs, and distributed caches reach for them constantly.

Lesson 9: Greedy Algorithms — When being selfish is optimal

Sat, 17 Aug 2024 00:00:00 +0000

Greedy algorithms have a simple idea at their core: at each step, make the locally optimal choice. No looking ahead, no considering alternatives, no backtracking. Just take the best available option right now and trust that it leads to a globally optimal result.

The catch is that this only works for specific problem structures. Use greedy when the problem has the greedy choice property — the locally optimal choice is always part of a globally optimal solution. When this holds, greedy is elegant and fast. When it does not, greedy gives you a wrong answer with no warning.

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 8: Memory-Mapped IO — How Databases Read Files

Tue, 13 Aug 2024 00:00:00 +0000

I was reading about how RocksDB works one evening and kept seeing references to mmap for reads. I had heard of memory-mapped files but thought of them as a niche optimization. Then I realized: SQLite uses mmap. WiredTiger (MongoDB’s storage engine) uses mmap. LMDB is built almost entirely around mmap. Even some Postgres configurations use mmap for WAL. Understanding mmap explains a lot about how high-performance storage works, why some databases are so fast for random reads, and why memory and I/O are so deeply intertwined at the OS level.

Lesson 7: On-Call Engineering — Reducing toil, improving reliability

Sun, 11 Aug 2024 00:00:00 +0000

I did 12 months of on-call on a team that hadn’t invested in reliability. The rotation was weekly. In a bad week, I’d get 15-20 pages. A good week was 5. I was exhausted by the end of my shift, and the paging frequency had barely changed over those 12 months. We were fixing incidents, not fixing the causes. The next team I joined approached on-call differently: on-call was treated as a reliability sensor, not a firefighting rotation. Pages were tracked, patterns identified, and root causes fixed. By month 6 I was averaging 2 pages per week on-call. The work we did during on-call made future on-call better.

Lesson 8: Replication — Streaming, Logical, and Failover

Fri, 09 Aug 2024 00:00:00 +0000

The first time I had to fail over a Postgres primary, it was 2 AM, the primary was not responding, and I genuinely did not know whether the replica was up to date or 10 minutes behind. We recovered, but that experience drove me to actually understand replication — not just “the replica gets the writes somehow” but exactly what data is shipped, when it arrives, and what happens when the primary dies. It turns out the mechanism is elegant and directly connected to the WAL we covered in Lesson 3.

Lesson 2: Deployments and Scaling — Rolling updates, HPA, VPA

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

The week before a major product launch, our Kubernetes cluster started evicting pods. Traffic was spiking as we ran load tests, but instead of scaling up, the HPA was oscillating — scaling up, then the new pods were getting OOMKilled, then scaled down, then up again. Pods were in CrashLoopBackOff, the HPA metrics were lagging behind the actual load, and I was watching health check failures cascade. It turned out our resource requests were wildly inaccurate — set once during initial deployment and never updated as the service’s actual usage changed. That day I learned that Deployments and autoscaling aren’t fire-and-forget configurations.

Lesson 7: Migration Strategies — Strangler fig and feature flags

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

Rewrites are seductive. The existing system is messy, it’s slow to change, and the new system in your head is clean and fast and well-designed. Then you start the rewrite. Six months in, you’ve rebuilt 40% of the functionality and the remaining 60% is more complex than you thought. Meanwhile, the old system keeps shipping features. The new system falls behind, gets cancelled, and you’re back where you started, except now you’ve lost six months and the team is demoralized. I’ve seen this happen twice. The third time, we used the strangler fig pattern instead, and it worked.

Lesson 9: Tries — Prefix matching, autocomplete, routing tables

Tue, 06 Aug 2024 00:00:00 +0000

When you type “ath” into a search box and it suggests “atharva,” “athens,” and “athletics,” that’s a trie. When an IP packet arrives at a router and the router decides which interface to forward it to, that’s a trie (specifically a Patricia trie). When your web framework matches /api/users/:id against an incoming URL, the fast implementations use a trie.

Tries (pronounced “try,” from “retrieval”) are specialized trees for string keys. They trade memory for speed in prefix-matching scenarios, and they make certain string operations fundamentally faster than any other structure.

Lesson 8: Design a URL Shortener — The Classic, Done Properly

Sun, 04 Aug 2024 00:00:00 +0000

The URL shortener is the “Hello World” of system design interviews. It appears deceptively simple: take a long URL, return a short one. But if you treat it superficially, you miss what the interviewer is actually testing: your ability to think through ID generation at scale, read-heavy caching, redirect semantics, analytics storage, and data modeling. Done well, the URL shortener problem touches nearly every fundamental we’ve covered so far.

The Core Concept

A URL shortener has two primary operations:

Lesson 7: Service Mesh — Sidecar proxies and mTLS without code

Sat, 03 Aug 2024 00:00:00 +0000

A team I worked with had seventeen microservices. Each service had its own implementation of retry logic, circuit breaking, timeout handling, and mutual TLS. Some used libraries, some rolled their own. When we needed to update the TLS certificate rotation policy, it touched eleven different code repositories, four different languages, and took two months. Then we introduced Linkerd and moved all of that to the infrastructure layer. The services still did their jobs. The networking became someone else’s problem — specifically, the platform team’s.

Lesson 2: Feature Stores — Why feature engineering is 80% of ML

Fri, 02 Aug 2024 00:00:00 +0000

There is a saying in machine learning that is so universally acknowledged it has become a cliché: 80% of the work in any ML project is feature engineering. I spent a long time thinking this referred to the cognitive labor — the domain expertise required to craft meaningful features. It does, in part. But the deeper meaning is operational. The 80% is not just about what features to build; it’s about how to compute them consistently, store them efficiently, retrieve them with sub-millisecond latency at serving time, and keep them synchronized between the training pipeline and the production system.

Lesson 8: Dynamic Programming Intuition — Memoization, not memorization

Fri, 02 Aug 2024 00:00:00 +0000

Dynamic programming has an intimidating reputation. The name sounds academic, the problems in textbooks often involve sequences and matrices, and the “aha moment” is notoriously hard to force. I spent a long time treating DP as an interview preparation topic rather than a tool I would actually use. That changed when I built a pricing engine and realized I had been reimplementing DP badly — without knowing it — by computing the same values over and over in nested function calls.

Lesson 7: Containers from Scratch — Namespaces, Cgroups, What Docker Does

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

I spent the first two years of my career using Docker without understanding what it was actually doing. I thought containers were a “lightweight VM” — some kind of virtualization. Then I read Liz Rice’s “Containers from Scratch” talk and wrote a 100-line container runtime in Go. Containers are not virtual machines. They are just Linux processes with restricted views of the system, implemented using two kernel features: namespaces and cgroups. Once you see how simple the underlying mechanism is, you understand exactly what Docker adds and why containers behave the way they do.

Lesson 6: Feature Flags — Progressive rollout and kill switches

Sun, 28 Jul 2024 00:00:00 +0000

We deployed a new checkout flow on a Friday afternoon. It had passed code review, passed testing, passed staging load tests. By Friday evening, the error rate was climbing. The new flow had a race condition that only manifested under specific mobile browser timing that we hadn’t tested. Without a feature flag, the fix would have required an emergency deployment — 25 minutes of build time, deployment, and validation. With a feature flag, the rollback was turning off a switch. Thirty seconds.

Lesson 7: Connection Pooling — What PgBouncer Actually Does

Sat, 27 Jul 2024 00:00:00 +0000

A Postgres connection is not cheap. When I first scaled a service from a single server to 20 replicas — each running a Go application with database/sql’s default pool settings — the database became the bottleneck almost immediately. Not because the queries were slow. Because we had 20 × 100 = 2,000 open connections, each consuming RAM on the Postgres server, and Postgres was spending more time managing connections than executing queries. This is the problem PgBouncer solves, and understanding how it works makes you a much better architect of backend systems.

Lesson 2: Raft Consensus — The consensus algorithm you can actually understand

Fri, 26 Jul 2024 00:00:00 +0000

When I first tried to understand Paxos — the original distributed consensus algorithm — I read the paper three times and still felt like I was missing something. I could follow each step individually, but I couldn’t build a mental model of why it worked or what the invariants were. Raft was designed specifically to fix that. Its paper is literally titled “In Search of an Understandability: The Raft Consensus Algorithm.” After reading it, I could explain it to someone else. That’s the bar Raft was designed to clear, and it does.

Lesson 2: Parsing — Tokens to AST, recursive descent

Thu, 25 Jul 2024 00:00:00 +0000

The lexer gave us tokens. The tokens are still flat — a sequence with no hierarchy. The expression 1 + 2 * 3 produces six tokens, but it does not yet say that 2 * 3 should be computed before adding 1. That grouping, that hierarchy, is what the parser builds. By the time the parser is done, we have a tree. A specific kind of tree: an Abstract Syntax Tree, or AST. Everything after the parser works on this tree: evaluation, type checking, code generation, optimization. The tree is the program.

Lesson 6: API Versioning — URL, header, or content negotiation

Wed, 24 Jul 2024 00:00:00 +0000

The first time I shipped a breaking change to a production API without a version, I got an incident at 2am because a partner integration stopped working. They’d been calling /api/orders for six months. I changed the response shape. Their code broke. That was when “API versioning” moved from “thing to do eventually” to “thing to do before you ship anything external.”

There’s no universally right answer to how you version APIs. There are tradeoffs, and the choice you make will shape your codebase for years. Here’s how I think about it.

Lesson 8: Graphs — You're solving graph problems without knowing it

Tue, 23 Jul 2024 00:00:00 +0000

Most engineers don’t think of themselves as solving graph problems. They think they’re deploying microservices, resolving package dependencies, routing network traffic, or modeling social connections. But the underlying structure in all of these is a graph, and the algorithms that make those systems work — Dijkstra’s, topological sort, BFS, DFS — are graph algorithms.

Once I started seeing graphs everywhere, I started solving systems problems better. Let me show you the representation, the key algorithms, and the production contexts where this thinking pays off.

Lesson 7: Rate Limiting — Token Bucket, Sliding Window, Distributed

Sun, 21 Jul 2024 00:00:00 +0000

Without rate limiting, a single misbehaving client can consume all your resources and deny service to everyone else. A bug in a client that retries in a tight loop. A competitor scraping your API. A DDoS attack. A feature that accidentally calls your endpoint ten times per button click. Rate limiting is the mechanism that prevents any of these from taking down your service — it’s the first line of defense between the internet and your origin.

Lesson 7: Shortest Path — Dijkstra in routing and network optimization

Fri, 19 Jul 2024 00:00:00 +0000

When I joined a team building a multi-region traffic routing system, the first thing I had to understand was why the routing decisions were not always the geographically shortest path. The system was using Dijkstra’s algorithm, but the edge weights were not just latency — they incorporated bandwidth cost, current utilization, failure rates, and SLA constraints. Dijkstra did not care what the weights meant. It just found the minimum cost path. That is its power.

Lesson 6: gRPC and Protobuf — Binary protocols and streaming

Wed, 17 Jul 2024 00:00:00 +0000

The first JSON API I replaced with gRPC was passing []Order objects around — each order had about 40 fields, most of which the caller never used. The JSON payload for a list of 100 orders was around 180KB. After the migration it was 22KB, and the serialization time in benchmarks dropped by 8x. But more than the performance numbers, what I noticed was the schema. Proto files are contracts. When a field changes, you know it. With JSON, you find out when things break in production.

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: Signals — SIGTERM vs SIGKILL and Graceful Shutdown

Sun, 14 Jul 2024 00:00:00 +0000

The first time I deployed a service to Kubernetes and watched it restart, I noticed that requests in flight were sometimes failing with connection resets. The pod was receiving 502 responses for a few seconds before it disappeared. I had heard of “graceful shutdown” but hadn’t implemented it. Kubernetes sends SIGTERM before killing a process, giving it time to finish in-flight requests — but my service was either ignoring the signal or exiting immediately, cutting off connections mid-request. Learning how signals work at the OS level, and then implementing correct signal handling in Go, fixed the issue permanently.

Lesson 5: Load Testing — k6, vegeta, realistic patterns

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

We load-tested our new checkout service before launch. 1,000 virtual users, 10 minutes, all hitting /v1/checkout sequentially. It passed with excellent numbers. Launch day: real traffic hit the service, and it fell over at 200 concurrent users. The problem was our test. Real users don’t all call the same endpoint in sequence. They browse, add to cart, apply discount codes, fill in addresses, and then checkout — a session that touches 8 different endpoints over 4 minutes. Our test didn’t model this. Our test was measuring the wrong thing.

Lesson 1: WASM from Go — Compile Go to WebAssembly and run it anywhere

Fri, 12 Jul 2024 00:00:00 +0000

I came to WebAssembly skeptically. The pitch — “run code anywhere, at near-native speed, in a sandboxed environment” — sounded like the kind of claim that looks great in a conference talk and falls apart in production. It took a specific use case to make me take it seriously: I needed to run the same validation logic in three environments — a Go backend, a JavaScript frontend, and a CLI tool — without maintaining three separate implementations of the same business rules.

Lesson 6: Query Planning and EXPLAIN — Reading Execution Plans

Thu, 11 Jul 2024 00:00:00 +0000

The first time I ran EXPLAIN ANALYZE on a slow query, I stared at the output for five minutes and understood none of it. It looked like a compiler error message crossed with a financial report. Then a senior engineer walked me through it, and what had looked like noise resolved into a clear picture: this node was doing more work than the planner expected, this join strategy was wrong, this sort was spilling to disk. EXPLAIN ANALYZE is the most powerful tool in database performance work, and it takes an hour to learn but pays back every week for the rest of your career.

Lesson 7: Heaps and Priority Queues — Scheduling, top-K, and rate limiters

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

Every time your operating system picks the next process to run, it’s using a heap. Every time Kubernetes re-schedules a pod, it’s using a priority queue. Every time you’ve written a “get top 10 most frequent items from a billion-row stream,” the efficient solution involves a heap. These are workhorses of systems programming that look simple on paper and have genuinely tricky implementation details.

The heap is also one of my favorite data structures to explain because it demonstrates a beautiful property: you can implement a tree efficiently inside an array, using only arithmetic to find parent and child nodes.

Lesson 5: DDD Essentials — Bounded contexts and aggregates

Sun, 07 Jul 2024 00:00:00 +0000

The concept of “customer” meant something different in every team I talked to at one company. To the billing team, a customer was a billing account. To the support team, a customer was a person who filed tickets. To the identity team, a customer was an authenticated principal. Every team had their own Customer struct, and syncing them was a full-time job. That’s the problem DDD’s bounded context concept solves — and it’s one of those ideas that sounds academic until you’ve suffered without it.

Lesson 6: CDNs — Put Your Bytes Close to Your Users

Thu, 04 Jul 2024 00:00:00 +0000

Physics is the enemy of performance. Light travels through fiber optic cables at about 200,000 km/s — roughly two-thirds the speed of light in a vacuum. A round-trip from New York to London is about 11,000 km each way. That means the minimum possible latency for that trip is 55ms. You cannot engineer your way past it. What you can do is stop making the trip at all. Content Delivery Networks are the infrastructure that puts popular content at the edge — closer to users, so the bytes never have to travel far.

Lesson 6: BFS and DFS — Dependency resolution, crawlers, cycle detection

Wed, 03 Jul 2024 00:00:00 +0000

Graph traversal sounds abstract until you realize that most interesting data in production is a graph. Service dependencies are a graph. Database foreign key relationships form a graph. Build tool dependencies, org charts, permission hierarchies, network topologies — all graphs. BFS and DFS are the two fundamental ways to walk them, and they show up in real engineering work more than almost any other algorithm.

I have used DFS to detect circular imports in a build system, BFS to find the shortest migration path between two schema versions, and both to debug why a dependency injection container was resolving services in the wrong order.

Lesson 5: WebSockets — Upgrade, framing, vs SSE vs polling

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

When I first built a real-time notification system, I reached for WebSockets because that’s what everyone said to use for “real-time.” Three months later I was debugging connection drops under load, wrestling with proxy timeouts, and fighting with nginx configuration. When I stepped back and actually thought about the access pattern — server pushing notifications to the browser, never the browser sending data to the server — I replaced WebSockets with Server-Sent Events in a weekend. The code got simpler, the proxies stopped complaining, and we had less to maintain. Picking the right tool requires understanding what each one actually does.

Lesson 1: Event Store Design — Append-only logs that are your source of truth

Sat, 29 Jun 2024 00:00:00 +0000

My first encounter with event sourcing was a financial system that needed a complete audit trail. The business requirement was clear: every change to an account balance had to be traceable — who changed it, when, why. The first approach was an audit log table alongside the main accounts table. We’d write to both in a transaction. Within six months, the audit table was out of sync with the accounts table. Bugs in the dual-write logic, a migration that updated account records without touching the audit log, a direct database fix that bypassed the application layer. The audit log was nearly useless. The core insight I eventually arrived at: the audit log shouldn’t be a secondary record — it should be the primary record. That’s event sourcing.

Lesson 5: Epoll and IO Multiplexing — How Go''s Netpoller Works

Thu, 27 Jun 2024 00:00:00 +0000

I used to wonder how a Go HTTP server could handle 100,000 concurrent connections with only 8 OS threads. If each connection required a dedicated thread, you would need 100,000 threads — which would require roughly 800 GB of stack space and would spend all their time in the kernel scheduler. The answer is epoll: a Linux kernel interface that lets a single thread wait on thousands of file descriptors simultaneously and be notified only when one is ready for I/O. Go’s runtime uses epoll internally as the foundation of its network I/O model. This lesson explains how.

Lesson 6: B-Trees and B+ Trees — How every database index actually works

Wed, 26 Jun 2024 00:00:00 +0000

Every time PostgreSQL, MySQL, SQLite, or MongoDB uses an index, it’s almost certainly a B-tree or B+ tree underneath. Not a binary search tree — a B-tree. The difference matters more than most engineers realize, and it comes down to one thing: disk read costs.

I’ve seen engineers add indexes blindly to fix slow queries without understanding what an index actually is. When you understand B-trees, you understand why some indexes help more than others, why certain query patterns can’t use indexes, and why index-heavy tables slow down on writes.

Lesson 4: Monitoring and Alerting — SLOs and alert fatigue

Mon, 24 Jun 2024 00:00:00 +0000

The on-call rotation I inherited had 47 active alerts. On a bad week, the on-call engineer got paged 30 times. Most pages were “something might be wrong” noise — high CPU on one instance, a spike in error rate that self-resolved in 30 seconds, disk space at 70% on a server with months of capacity remaining. Engineers stopped taking the pages seriously. Then the one real incident got buried in the noise, and we had a 4-hour outage because no one treated the first alert seriously. Alert fatigue is not a monitoring problem. It’s an architecture-of-trust problem.

Lesson 5: Transaction Isolation — Read Committed vs Serializable

Sun, 23 Jun 2024 00:00:00 +0000

I shipped a bug once that allowed a user to spend the same gift card balance twice. Two requests arrived nearly simultaneously, both read the same balance, both decided the balance was sufficient, both deducted it, and both succeeded. The database did exactly what I asked. The problem was what I asked for: I assumed reads were consistent across statements within a transaction, but I was running at the default isolation level. Understanding the four isolation levels — and what each one actually protects you from — is not academic. It is the difference between shipping correct financial code and shipping race conditions.

Lesson 4: CQRS — When reads and writes need different models

Fri, 21 Jun 2024 00:00:00 +0000

I maintained an e-commerce admin dashboard that had a query so complex it took 12 seconds to run. It joined seven tables across the orders, inventory, and customers domains to build a summary view of “all orders pending fulfillment, with customer tier, item details, and warehouse stock levels.” Every time the admin loaded the page, twelve seconds. We tried indexes, caching, materialized views — all helped at the margins. The fundamental problem was that we were asking our write-optimized relational model to answer a read-optimized reporting question. Separating the read model was the only real fix.

Lesson 5: Message Queues — Decoupling Services Without Losing Messages

Wed, 19 Jun 2024 00:00:00 +0000

Synchronous calls are elegant until they’re not. Service A calls Service B. B is slow. A waits. A’s request pool fills up. A becomes slow. The caller of A waits. The whole request chain stalls. Add a few more services in the chain and you have a distributed deadlock in slow motion. Message queues exist to break this dependency — to let a producer say “here’s some work” and move on, without caring whether the consumer is fast, slow, or temporarily down.

Lesson 5: Hashing and Consistent Hashing — How load balancers distribute traffic

Mon, 17 Jun 2024 00:00:00 +0000

I did not think much about hashing until I had to explain why a cache cluster was unusable after we added two new nodes. We had doubled the cache hit rate over six months, added two boxes to handle the load, and immediately destroyed most of our cached data. Every key rehashed to a different server. Cache hit rate dropped from 85% to under 10%. We were hammering the database.

Lesson 4: DNS — Resolution, caching, and why changes take time

Sat, 15 Jun 2024 00:00:00 +0000

We pushed a production incident fix at 3am — rotated to a new IP address for a critical service, updated the DNS record, set the TTL to 60 seconds. Thirty minutes later, half our users were still hitting the broken server. The other half were fine. We had updated the DNS record correctly. The TTL had expired. Yet somehow, stale answers were persisting. That night taught me more about DNS than any documentation had.

Lesson 5: Trees and BSTs — Why your database is a tree

Thu, 13 Jun 2024 00:00:00 +0000

When you run SELECT * FROM orders WHERE user_id = 42, your database doesn’t scan every row. It walks a tree. Understanding why databases chose trees over hash maps — and which kind of tree, and why — is one of those “oh, everything makes sense now” moments that changes how you design systems.

Let me start with binary search trees, get honest about their weaknesses, and set up the foundation for B-trees in the next lesson.

Lesson 4: TCP/IP Stack — SYN Floods, TIME_WAIT, Connection Tuning

Tue, 11 Jun 2024 00:00:00 +0000

A load test I ran against a Go HTTP server one afternoon produced a strange result: throughput leveled off at about 30,000 requests per second and couldn’t go higher, even though CPU was at 30%. Running netstat -an | grep TIME_WAIT | wc -l showed over 28,000 connections in TIME_WAIT state. The kernel was running out of local port numbers. Understanding TCP connection states — and how to tune Linux’s TCP stack — unblocked the test and taught me more about networking than any course had. This lesson covers the TCP mechanics that actually matter for backend engineers running high-throughput services.

Lesson 4: MVCC — How Postgres Handles Concurrent Reads and Writes

Sun, 09 Jun 2024 00:00:00 +0000

One thing that puzzled me early on was how Postgres could let me read from a table while someone else was writing to it — without locking me out and without me seeing half-written data. Most systems I had worked with used explicit read locks, which meant readers and writers had to take turns. Postgres doesn’t do that. Reads never block writes, and writes never block reads. The mechanism that makes this possible is called Multiversion Concurrency Control, or MVCC, and it works by keeping multiple versions of every row simultaneously.

Lesson 3: Incident Response — Postmortems and blameless culture

Sat, 08 Jun 2024 00:00:00 +0000

The first major incident I was on-call for, I spent 90 minutes trying to fix the problem and 30 minutes frantically communicating to stakeholders in a panic. The second one, I followed a runbook and spent the 90 minutes coordinating, communicating clearly, and delegating diagnosis — while the problem was resolved in 40 minutes. The difference wasn’t technical skill. It was process. Incident response is a skill you can learn and practice, and it makes a measurable difference in how quickly you restore service and how well the team learns from failures.

Lesson 1: GraphQL vs REST — When GraphQL wins and when it doesn't

Thu, 06 Jun 2024 00:00:00 +0000

I spent about six months being wrong about GraphQL. My first exposure to it was a rewrite pitch from a frontend engineer who was tired of making five REST calls to assemble one screen. “GraphQL solves this,” they said, and the demo looked compelling. A single query, exactly the fields you need, one round trip. I was sold before thinking carefully about what we were buying.

The rewrite happened. It took eight months instead of four. Some of the problems we were trying to solve got better. Others got worse. Looking back, the mistake wasn’t choosing GraphQL — it was not being rigorous about where GraphQL actually wins and where it doesn’t before committing.

Lesson 4: Database Scaling — Read Replicas, Sharding, and When Each Helps

Wed, 05 Jun 2024 00:00:00 +0000

Your startup ships, gains traction, and one day your database becomes the bottleneck. Queries slow down. CPU spikes. The single machine hosting your Postgres instance can’t keep up. This is one of the most predictable problems in engineering, yet I’ve seen teams reach it completely unprepared because they’d never thought carefully about how databases scale. The right solution depends entirely on whether you’re read-heavy or write-heavy, whether your data is relational or not, and whether your workload is even or spiky.

Lesson 3: Event-Driven Architecture — Events vs commands

Tue, 04 Jun 2024 00:00:00 +0000

I used to use “event” and “command” interchangeably. A message is a message, right? Then I started debugging an event-driven system where the payment service was publishing ProcessPayment events, the order service was publishing CreateShipment events, and two teams were arguing about who owned the workflow. The problem was naming: they were publishing commands disguised as events. The distinction isn’t pedantic — it determines who owns the workflow and how the system evolves.

Lesson 1: ML Pipelines — From raw data to deployed model

Sun, 02 Jun 2024 00:00:00 +0000

The first time I built a “production ML pipeline,” it was a cron job that ran a Python script, trained a model, and saved the artifact to disk. It worked, until it didn’t. The model silently degraded over three weeks because the training data schema changed and nobody noticed. There were no tests, no validation, no monitoring. That experience, embarrassing as it was, taught me more about ML system design than any paper on model architecture.

Lesson 4: Two Pointers and Sliding Window — Stream processing in disguise

Sat, 01 Jun 2024 00:00:00 +0000

The first time I recognized the sliding window pattern outside a textbook, I was reading the source code for a rate limiter. There was no comment saying “sliding window algorithm here.” There was just a loop, two indices into a circular buffer, and some simple arithmetic that maintained a count of events in the last N seconds. Once I saw it, I started seeing it everywhere — in network flow control, in moving average calculations, in deduplication logic.

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 3: TLS Handshake — What happens in those 2 round trips

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

A colleague once asked me why adding TLS to a service increased our P99 latency by 50ms. She had measured it carefully, switching between HTTP and HTTPS in a load test. My first instinct was to say “encryption overhead” but that’s wrong — modern CPUs with AES-NI can encrypt gigabytes per second. The actual cost is the handshake. Once I explained what was actually happening in those first few round trips, the answer to “how do we fix it” became obvious: stop creating new connections.

Lesson 4: Stacks and Queues — The structures hiding in every system

Tue, 28 May 2024 00:00:00 +0000

Every time you make a function call, your program uses a stack. Every HTTP request in a web server sits in a queue. Every undo operation in your IDE is a stack. These structures are so fundamental they’re baked into the hardware itself — the CPU has dedicated stack instructions.

Yet I consistently see engineers reach for generic slices or channels when a properly implemented stack or queue would be both clearer and faster. Let me show you what these structures actually are, why they’re the shape they are, and where they show up in the systems you work on every day.

Lesson 3: File Descriptors — Why Too Many Open Files Kills Your Server

Mon, 27 May 2024 00:00:00 +0000

I got a 3 AM page for a service that was returning connection errors to every client. The application logs said dial tcp: lookup ...: too many open files. We hadn’t changed anything. Load was normal. But over 48 hours, something had been slowly accumulating open file descriptors and not closing them, and we hit the per-process limit. Restarting the service fixed the immediate problem; understanding why it happened required me to actually learn what file descriptors are and how the kernel manages them.

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: Pod Design Patterns — Sidecar, ambassador, adapter

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

The first time I deployed a service to Kubernetes, I put everything in a single container. Logging, metrics, TLS termination, the actual application — all in one Docker image. It worked, but the image was massive, updating any single concern meant rebuilding and redeploying the whole thing, and the application team had to understand infrastructure concerns they shouldn’t need to care about. The sidecar pattern was the thing that changed how I thought about container composition.

Lesson 3: Write-Ahead Log — How Databases Survive Crashes

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

Databases promise durability. When INSERT returns successfully, your data is safe — even if the server loses power a millisecond later. For a long time I accepted this as magic. Then I started reading about what actually happens when Postgres writes data, and the mechanism behind that promise is both elegant and counterintuitive: to make writes safe, you write them twice. The first write goes to a sequential log. The second write goes to the actual data file. And the log is what saves you when things go wrong.

Lesson 2: Code Review That Works — What to look for

Wed, 22 May 2024 00:00:00 +0000

I’ve been on the wrong end of bad code reviews in both directions. Reviews that were nitpick sessions about variable naming while missing a race condition. Reviews that rubber-stamped everything because the reviewer was busy. And I’ve given both kinds myself. It took a few years, a few incidents, and a few honest retrospectives to develop a framework for reviews that actually improve code quality without burning out reviewers or demoralizing authors.

Lesson 3: Caching — The Hardest Easy Problem in CS

Mon, 20 May 2024 00:00:00 +0000

Phil Karlton supposedly said: “There are only two hard things in Computer Science: cache invalidation and naming things.” He was joking, but also completely serious. Caching is the answer to nearly every “make it faster” problem in system design. It’s also the source of some of the most insidious bugs in production: stale data served with confidence, cache stampedes that take down your database, memory explosions from an unbounded cache. The concept is simple. Getting it right is not.

Lesson 2: Clean Architecture — Not the textbook version

Sun, 19 May 2024 00:00:00 +0000

I’ve read the Clean Architecture book. I’ve also seen teams implement it so literally that they had six layers of indirection for a CRUD endpoint: a controller called a use case, which called a domain service, which called a port, which went through an adapter, which called a repository, which hit the database. Each hop had its own error mapping. Changing a database column required touching eight files. That’s not clean. That’s engineering theater.

Lesson 3: Binary Search — The most useful algorithm you'll use weekly

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

Binary search has a reputation as a simple algorithm — and it is, conceptually. Divide the search space in half, check the middle, repeat. Every programmer knows this. Yet I have seen engineers reach for a linear scan when binary search would have solved the problem in a fraction of the time, and I have also seen subtly buggy binary search implementations that work 99.9% of the time and silently fail on edge cases.

Lesson 1: Leader Election — Someone has to be in charge

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

I spent three days debugging a production incident where two nodes in our cluster both believed they were the primary. Each was accepting writes. Each was replicating to followers. Each was convinced the other was dead. By the time we noticed, we had diverged state that took two more days to reconcile. That incident made me obsessive about leader election — not as an academic concept, but as a concrete engineering problem with real failure modes.

Lesson 3: Hash Maps — O(1) with asterisks

Wed, 15 May 2024 00:00:00 +0000

Hash maps are the workhorse of production software. Nearly every caching layer, session store, deduplication system, and configuration lookup you’ve ever written relies on one. They’re fast, they’re flexible, and they’re genuinely O(1) — with some asterisks that matter enormously in production.

I want to walk through how they actually work, because the “O(1) lookup” claim hides a lot of complexity that shows up in the worst possible moments: under load, with adversarial input, or when your hash function is subtly wrong.

Lesson 2: HTTP/2 and HTTP/3 — Multiplexing and QUIC

Tue, 14 May 2024 00:00:00 +0000

The first time I looked at a waterfall chart in Chrome DevTools and saw a hundred requests stacking up like rush-hour traffic, I knew HTTP/1.1 was the problem. We had a dashboard loading twelve API calls and a handful of assets, and they were all waiting in line. Not because the server was slow — it was idle — but because the browser had a six-connection-per-host limit and every request had to wait its turn. That was my introduction to why HTTP/2 exists, and it changed how I think about protocol design.

Lesson 2: Virtual Memory — 1GB RSS but Only 50MB is Real

Sun, 12 May 2024 00:00:00 +0000

Early in my career I deployed a Go service and checked top. The VIRT column showed 1.2 GB. I nearly had a heart attack — our server had 4 GB of RAM and I thought the service was consuming nearly a third of it. A senior engineer laughed and told me to look at RES instead: 52 MB. I had no idea what the difference was. Understanding virtual memory is fundamental to reading memory metrics correctly, debugging out-of-memory kills, and understanding how processes interact with the kernel.

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 2: B-Tree Indexes — O(n) to O(log n) in one CREATE INDEX

Wed, 08 May 2024 00:00:00 +0000

I once joined a team that had a users table with 8 million rows. The GET /users/{email} endpoint was consistently timing out under load. When I ran EXPLAIN ANALYZE on the query, I saw it: Seq Scan on users (cost=0.00..180000.00 rows=1 width=120) (actual rows=1 loops=1). It was reading every single row — all 8 million of them — to find one user by email. Adding a single index fixed it in under five minutes. That experience made me want to actually understand what an index is, not just that it makes things faster.

Lesson 1: Git Beyond Basics — Rebase, bisect, worktrees

Tue, 07 May 2024 00:00:00 +0000

Most engineers use maybe 15% of Git. add, commit, push, pull, branch, merge, and status covers daily work. That’s fine until you need to find which commit introduced a regression across 300 commits, or you need to untangle a messy history before merging, or you want to work on three features simultaneously without context-switching overhead. The commands I’m covering here don’t come up every day. When they do, they save hours.

Lesson 1: Lexing — Turning text into tokens

Mon, 06 May 2024 00:00:00 +0000

I wrote my first lexer as a side project after reading the first chapter of “Writing an Interpreter in Go.” I expected it to be hard. It was not. A lexer is conceptually one of the simpler pieces of a compiler: read characters, group them into meaningful chunks, throw away whitespace. What surprised me was how much clarity it brought to everything downstream. Once I had tokens instead of characters, every subsequent step became easier to reason about. The text became structured. And the structure was entirely my design.

Lesson 2: Load Balancing — L4 vs L7 and Why It Matters

Sun, 05 May 2024 00:00:00 +0000

The first time I drew a system design diagram in an interview, I drew a box labeled “load balancer” and drew arrows from clients to it, and from it to servers. My interviewer asked, “What kind of load balancer?” I didn’t have an answer. I knew load balancers existed. I didn’t know they made fundamentally different decisions at different network layers — and that the choice between them shapes what your system can and cannot do.

Lesson 1: Monolith First — Starting with microservices is usually wrong

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

I’ve seen two teams start new products with microservices. One spent four months before they had anything deployed — Kubernetes setup, service discovery, distributed tracing, a CI/CD pipeline for twelve repos, and debates about how to split domains they hadn’t fully understood yet. They ran out of runway. The other team I worked on started with a monolith, shipped their first real user feature in three weeks, and only extracted services when the actual pain of growth made the benefit obvious. We’re still running that system, and it handles tens of millions of requests a day.

Lesson 2: Sorting in Practice — When to sort and why TimSort won

Wed, 01 May 2024 00:00:00 +0000

Sorting is one of those topics that feels like a solved problem until you actually need to care about it. Every language ships a standard sort. You call it, it works, you move on. But I have run into subtle production bugs caused by not understanding what the sort is actually doing — unstable sorts breaking tie-breaking logic, sorts on large datasets consuming unexpected memory, and sort comparators with subtle bugs that triggered Go’s sort to panic.

Lesson 1: TCP Deep Dive — Three-way handshake, congestion, Nagle

Mon, 29 Apr 2024 00:00:00 +0000

I used to treat TCP as a black box. Data goes in one side, data comes out the other — reliably, in order, no duplicates. That was all I needed to know, right? Then I started debugging latency spikes in a payment service and spent three days chasing a 200ms tail latency that turned out to be Nagle’s algorithm fighting with delayed ACKs. After that, I stopped treating TCP as a black box.

Lesson 2: Linked Lists — Almost never the right choice

Sun, 28 Apr 2024 00:00:00 +0000

Linked lists are the most over-taught data structure in computer science and the most under-used structure in production systems. I’ve reviewed hundreds of pull requests across distributed systems codebases, and I can count on one hand the times a linked list was genuinely the right call.

That said, understanding why linked lists are usually wrong teaches you something profound about how computers actually work. And there are a handful of situations where they’re exactly right — and when those situations come up, you need to recognize them fast.

Lesson 1: Processes and Threads — What Goroutines Map To

Thu, 25 Apr 2024 00:00:00 +0000

When I first started using Go seriously, I accepted goroutines as “lightweight threads” without really understanding what that meant. The Go runtime creates them, schedules them, and I launch them with go. Then I got curious: what does the OS actually see? When I run 10,000 goroutines, does the kernel manage 10,000 things? The answer is no — and understanding why requires understanding the difference between processes, kernel threads, and userspace threads. It also explains why goroutines scale so much better than Java threads or Python threads.

Lesson 1: How a Query Executes — Parser to Planner to Disk

Mon, 22 Apr 2024 00:00:00 +0000

Every time I call db.QueryContext(ctx, "SELECT * FROM orders WHERE user_id = $1", userID) in Go, I used to think the database just “found” the rows. It wasn’t until I started debugging a production slowdown — a query that was fast for months and then suddenly wasn’t — that I actually traced what happens between the moment my application hands off that SQL string and the moment rows come back. Understanding that pipeline changed how I write queries, design schemas, and diagnose performance problems.

Lesson 1: How the Internet Works — DNS, TCP, HTTP, TLS in 15 Minutes

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

Every system design interview starts with the same silent assumption: you already know how the internet works. Interviewers won’t ask you to explain DNS. But when you confidently say “the client calls the API” without being able to say what actually happens between those words, the cracks show up in your design. Understanding the layers — DNS, TCP, HTTP, TLS — isn’t trivia. It’s the mental model that tells you where latency hides, why connections are expensive, and what breaks under load.

Lesson 1: Big-O Thinking — Will this scale to 1M records?

Thu, 18 Apr 2024 00:00:00 +0000

I spent two years writing Go services before I really internalized Big-O. Not because I didn’t know the notation — every CS course teaches you to recite O(n log n) — but because I never tied it to a real decision I had to make in production. It clicked for me the day a coworker asked, “will this work when we have a million users?” and I had no honest answer.

Lesson 1: Arrays and Memory Layout — Cache lines decide your performance

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

I spent two years writing Go services before I genuinely understood why iterating over a two-dimensional slice in the wrong order could tank my throughput by 5x. It wasn’t a bug. It wasn’t a bad algorithm. It was cache lines.

Arrays are the first data structure everyone learns and the last one most engineers actually understand. This is my attempt to fix that — not with theory, but with the reasoning that makes you a better systems engineer.

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.