Code With Wilson

Day 2, Problem 1 of LeetCode's Top Interview 150. This is one of those rare problems where the *natural* solution is fine, the *clever* solution is good, and the *optimal* solution is famously elegant — to the point of being named after its inventor. The optimal solution is called the **Boyer-Moore Voting Algorithm**, and it's the kind of thing that takes 3 lines of code but earns "interview gold"...

Day 1, Problem 3 of LeetCode's Top Interview 150. The headline lesson of this episode: **problem qualifiers like "sorted" aren't decoration. They're optimization unlocks.** This problem reuses the slow/fast two-pointer scaffold from #27 Remove Element with one tiny change in the filter rule — but the *real* lesson is *why* that change works, and that lesson generalizes to dozens of other problems....

Day 1, Problem 2 of LeetCode's Top Interview 150. This is the cleanest possible introduction to a pattern called **slow/fast two-pointer** — also known as the "read pointer, write pointer" idiom. It looks deceptively easy. The trap isn't in the algorithm; it's in *understanding what "remove" actually means* when the problem says "in-place." By the end of this episode you should be able to answer:...

This is the first problem in LeetCode's official "Top Interview 150" list — Day 1, Problem 1. If you can think clearly about this one, you have the foundation for roughly 30 other problems in the same family. This episode assumes you already know the 6-phase framework (understand → recognize → brute force → optimize → implement → communicate). We're not going to belabor the structure. Instead, we'...

You're given an array and asked to find all unique triplets `(a, b, c)` where `a + b + c = 0`. Naive: three nested loops, O(n³). NeetCode's optimal: **sort the array, then for each `a`, run two pointers on the rest looking for `b + c = -a`**. O(n²) total. The clever parts are (1) sorting first to enable two pointers and (2) carefully skipping duplicates at three levels to avoid duplicate triplets...

Whenever a problem asks for the longest (or shortest) **subarray or substring** with some property, the answer is **sliding window**. Two pointers — `left` and `right` — define a window over the input. The right pointer expands the window; when the property breaks, the left pointer shrinks until the property holds again. NeetCode's canonical approach uses a **hashset** to track unique characters a...

You're given a list of stock prices and you need to find the maximum profit from buying once and selling once on a later day. The brute force is O(n²) — try every (buy, sell) pair. The optimization: as you walk the array, **maintain the minimum price seen so far**. At each day, the best possible profit *if you sold today* is `current_price - min_so_far`. Track the maximum across all days. **One pa...

Whenever a problem involves **matching pairs that nest** — parentheses, function calls, undo/redo, HTML tags — the answer is a stack. The stack remembers what's still "open" so you can match the next "close" against the most recent open. **The pattern is "last opened, first closed" = LIFO = stack.** Get this once and you transfer it to the next dozen stack problems instantly. Valid Parentheses is...

A palindrome reads the same forwards and backwards. The naive way is to reverse the string and compare. The optimal way is to walk two pointers from the ends inward, comparing characters. The two-pointer pattern is the single most common alternative to hashmap when the data has natural "structure from both ends" — symmetry, sortedness, monotonicity. **Two pointers is what you reach for when the pr...

This problem looks like it should be solved with division (compute total product, divide by each element). But the problem explicitly *forbids* division. That constraint forces you to invent the prefix/suffix product pattern: for each index, the answer is "everything to my left, multiplied by everything to my right." Build those two products in two linear passes — done. Product of Array Except Sel...

Top K Frequent reduces to a two-step pipeline: (1) count occurrences with a hashmap, (2) extract the top k counts using a selection algorithm. The whole interesting decision is *how* you do step 2 — heap, full sort, or bucket sort. **Bucket sort is the optimal answer; heap is the standard interview answer; full sort is the brute force.** Knowing all three and articulating the tradeoff is the senio...

Longest Consecutive Sequence asks for the longest run of consecutive integers in an unsorted array, in O(n) time. Sorting takes O(n log n), so we can't sort. The trick: **start a run only from a number that has no predecessor in the set**. That single observation collapses what looks like an O(n²) problem into a clean linear scan. Longest Consecutive Sequence is the **start-of-run** problem. The h...

Contains Duplicate is the degenerate case of Two Sum: instead of "have I seen the complement?", the question is just "have I seen *this*?" The answer is the foundation of every membership-test problem in LeetCode. **One pass, hashmap, return early on collision.** That's it. Contains Duplicate is the **membership test**. The hashset answers "have I seen this?" in O(1). Once you have that hammer, ev...

Group Anagrams demonstrates the upgrade from "hashmap as memory" to "hashmap as group-by." The whole problem becomes trivial once you see the move: compute a canonical signature for each string, use that signature as a dictionary key, and append every string with that signature to the same bucket. **The hashmap key is the real algorithm.** Group Anagrams is the canonical demonstration of "hashmap...

Anagram problems are about **canonical form**: two strings are anagrams if and only if their character counts are identical. The whole problem reduces to "build the count, compare the counts." Once you see that, every anagram-family problem (Valid Anagram, Group Anagrams, Find All Anagrams in a String) is the same move. Anagrams reduce to **comparing frequency tables**. Sorting is the brute force;...

Two Sum is not interesting because it's hard — it's interesting because it's the canonical demonstration of the single most common optimization move in all of LeetCode: trade space for time using a hashmap. This episode walks through the six-phase framework explicitly, applied to Two Sum, so the framework itself gets reinforced. Six topics: (1) Phase 1 understand the problem — restate, examples by...

What ML systems actually look like at frontier scale, why traditional systems thinking breaks, and where the engineering leverage lives. Six topics: (1) the scale of modern ML infrastructure — 1e26 FLOPs, billion-dollar starting prices, nuclear-power-plant data centers; (2) why ML systems are fundamentally different — absurdly simple programs, absurdly high performance demands (50% MFU), monocultu...

The framework matters more than any individual problem. Most beginners fail LeetCode by jumping to code; strong candidates do six distinct things in sequence and only touch the keyboard at phase 5. Walk-through of each phase: Phase 1 understand the problem (restate, examples, constraints); Phase 2 recognize the pattern (15-20 patterns cover 95% of interview problems); Phase 3 brute force first alw...

Capstone topic for the AI engineering discipline. An AI product is not 'an LLM call' — it's a seven-layer system where most production failures happen outside the model. Covers: the seven-layer architecture (frontend, orchestration, retrieval, guardrails, model, output filter, telemetry); observability and distributed tracing for multi-step agents; explicit vs implicit user feedback; the feedback...

A frontier LLM at $5 per million tokens looks cheap on the pricing page. Then the arithmetic: one million DAUs issuing one 2,000-token query each is two billion tokens per day, $10K per day, $3.6M per year — and that's just inference, before retrieval, embeddings, evals, or human review. **Inference optimization is serving the same intelligence at materially lower cost without breaking the quality...

When you build with foundation models, the model itself is largely a fixed input — you pick GPT, Claude, or Gemini, and you don't retrain weights. The variables you actually control are **the data going in**: training data if you fine-tune, the retrieval corpus if you do RAG, the prompt examples if you do in-context learning, the eval data you use to measure whether anything works. Every one of th...

Synthesis of the 105 RAG interview questions in the dedicated RAG Q-bank. Goes much deeper than Chapter 6 — into the engineering details interviewers actually probe for production RAG systems. Covers: the 4-step pipeline (index, retrieve, augment, generate), chunking trade-offs (size, overlap, semantic chunking), embedding choice (generic vs domain-tuned, dimensions vs storage), hybrid retrieval (...

Synthesis of the 33 AI Agents questions in the AI Engineer interview Q-bank. Goes deeper than Chapter 6 — into the production tradeoffs interviewers actually probe. Covers: the chatbot/RAG/agent distinction, the reason-act-observe loop (ReAct), planning patterns (ReAct vs Plan-and-Execute vs Reflexion), tool definitions and function calling, Anthropic tool use and MCP, memory layering (short-term...

Fine-tuning means teaching a model new **behaviors** by updating its weights. Different from prompting (no weight changes — steer in-context) and RAG (no weight changes — inject context at inference). **The hierarchy is prompting → RAG → fine-tuning, in that order**, because each step costs more, takes longer, and is harder to reverse than the last. Fine-tuning is the most powerful tool and the mo...

Two ideas, one chapter, same root limitation. A foundation model is **frozen at training time**, has a **bounded context window**, and **cannot act on the world**. **RAG (Retrieval-Augmented Generation)** injects fresh, private, or domain-specific knowledge at runtime by retrieving relevant chunks into the prompt — knowledge without retraining. **Agents** extend the model's reach by letting it cal...