applied build

A live-coding round that separates people who have shipped agents from people who have read about them. The signal is a real plan-act-observe loop, tools that hit an actual SQL database, guardrails that stop the obvious failures, and a concrete evaluation plan, not a single prompt that pretends to be an agent.

A bridge between classic DSA and modern RAG. The signal is building a working inverted index and a correct BM25 score by hand, reasoning about its complexity, and then knowing exactly when you would reach for embeddings and an ANN index instead.

The canonical multi-round build screen: a simple key-value store that grows new requirements every stage (TTL, transactions, scans). The signal is not stage 1, it is whether your code absorbs stage 4 without a rewrite. Here is how to design for it.

A credit ledger that grants GPU-hours, spends them, and expires unused grants. The trap is which grant to spend first. Here is the FIFO-by-expiry design.

Writes inside a transaction commit or get thrown away, and transactions nest. The overlay-stack design that makes rollback O(1) without touching the base.

A practical build screen: turn a stream of sampled call stacks into a flame tree, then report self-time vs total-time per function. The trap is conflating the two times. Here is how to aggregate the tree and rank the hot functions.

A grounded systems-coding screen: find files with identical content across a tree. The naive all-pairs hash is wasteful. The signal is the size prefilter and a cheap-hash gate before the full hash. Here is the layered approach.

The rotting-oranges family of build screens: a state spreads outward one step per tick across a grid, and the spec gains rules each round. The signal is multi-source BFS by layers, not per-cell loops. Here is the design that absorbs each new test case.

Cells hold values or formulas over other cells, and an edit must recompute dependents without looping forever. Dependency graph plus cycle detection.

Google's 'vibe coding' screen: the spec is deliberately vague and changes mid-interview. The signal isn't the algorithm, it's whether you clarify before coding, structure for change, and keep tests green while the requirements move. Here is how to run that loop.

A from-scratch classic that tests recursion plus the split criterion math. The signal is computing impurity correctly, choosing the best threshold by information gain, and knowing the stopping rules. Here is a clean recursive implementation.

A from-scratch favorite that tests linear algebra fluency. The signal is centering first, using SVD instead of forming the covariance matrix, and reading variance off the singular values. Here is the implementation and the details interviewers push on.

A from-scratch test of the EM algorithm and soft clustering. The signal is the two alternating steps (responsibilities then weighted re-estimation), log-sum-exp for stability, and knowing how GMM generalizes k-means. Here is the implementation.

A from-scratch test of how PyTorch actually works under the hood. The signal is building a computation graph during the forward pass, local derivatives per op, and a topological-order backward pass that accumulates gradients. Here is a minimal engine.

A from-scratch test of subword tokenization. The signal is greedy longest-match encoding against a fixed vocabulary, the continuation-prefix convention, and how WordPiece differs from BPE. Here is the implementation.

A from-scratch test of distributed input pipelines. The signal is partitioning data across workers with no overlap and no gaps, epoch-consistent shuffling with a shared seed, and handling the uneven-last-batch problem. Here is the implementation.

The classic recursive-descent exercise with an applied-AI twist: the JSON your model streams is truncated mid-token for the entire generation. The signal is a clean strict parser plus a small repair layer, not a second parser. Here is the implementation.

The most job-shaped coding screen in Applied AI: fan out N LLM calls without melting the rate limit or losing the batch to one bad request. The signal is in the retry policy, not the async syntax. Here is the version that passes.

The coding round version of the RAG question every candidate can describe in prose. Embed, index, retrieve, generate, cite. What separates a pass from a fail is the branch you write for when retrieval comes back with nothing worth quoting.

Everyone can recite the chunking tradeoff. Far fewer can write the splitter, keep the offsets a citation needs, and answer the question that kills the fixed splitter: what happens to a fact that straddles a boundary.

Every LLM product streams, and almost nobody can write the server. The interesting part is not the async generator, it is what happens when the user hits stop, the provider dies at token 90, or moderation flags text you have already put on the screen.

The applied data-wrangling screen: here is a grubby database, produce a clean analysis-ready table. The signal is profiling before transforming, doing set-based cleaning in SQL and row-level fixes in Python, joining without fanning out rows, and validating the output instead of trusting it.