applied build

A live-coding round that tells apart engineers who have shipped agents from those who have only read about them. Interviewers want a genuine plan-act-observe loop, tools that query a real SQL database, guardrails that block the obvious failures, and a concrete evaluation plan, rather than one prompt masquerading as an agent.

A bridge connecting classic DSA and modern RAG. Interviewers want to see you build a working inverted index and a correct BM25 score by hand, reason about its complexity, and then know precisely when you would switch to embeddings and an ANN index instead.

The classic multi-round build screen: a plain key-value store that gains new requirements at each stage (TTL, transactions, scans). The signal is not stage 1, it is whether your code takes on stage 4 without a rewrite. Here is how to design for it.

OpenAI's signature build screen: a credit ledger that issues GPU-hours, spends them, and lets unused grants lapse in issue order. The trap is charging against the right grant first. Here is the FIFO-by-expiry design that holds up through every follow-up.

A classic build screen: a key-value store whose writes inside a transaction can be committed or discarded, with transactions that nest. The trap is mutating the base store directly. Here is the overlay-stack design that keeps rollback O(1).

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

A grounded systems-coding screen: locate files with identical content across a tree. The naive all-pairs hash wastes work. The signal is the size prefilter plus a cheap-hash gate ahead of the full hash. Here is the layered approach.

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

Sierra's signature build screen: cells hold values or formulas that reference other cells, and editing one has to recompute its dependents without infinite loops. The signal is the dependency graph plus cycle detection. Here is the topological-eval design.

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

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

A from-scratch favorite that probes 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 build-it-yourself check on the EM algorithm and soft clustering. What matters is the pair of alternating steps (responsibilities, then weighted re-estimation), log-sum-exp for numerical stability, and seeing how GMM extends k-means. The code follows.

A build-it-yourself check on how PyTorch actually works under the hood. What matters is assembling a computation graph during the forward pass, local derivatives per op, and a topological-order backward pass that accumulates gradients. Below is a minimal engine.

A build-it-yourself check on subword tokenization. What matters is greedy longest-match encoding against a fixed vocabulary, the continuation-prefix convention, and how WordPiece diverges from BPE. The code follows.

A build-it-yourself check on distributed input pipelines. What matters 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. The code follows.

The classic recursive-descent exercise with an applied-AI twist: the JSON your model streams stays truncated mid-token for the whole generation. What matters is a clean strict parser plus a small repair layer, not a second parser. The code follows.

The most job-shaped coding screen in AI, ML, and GenAI engineering: fan out N LLM calls without melting the rate limit or losing the batch to one bad request. What matters is the retry policy, not the async syntax. Below is the version that passes.

The most-asked hands-on LLM exercise: a chat history that outgrows the context window. What gets scored is not the sliding window, it is the region eviction is never allowed to touch. Below is the version that passes.

Every RAG system packs a prompt, and the packing bug is always the same one: the input fits the window exactly, so the model has nowhere left to answer. The arithmetic here is what separates a candidate who has shipped from one who has read about it.

The lookup is three lines of linear algebra. What separates a cache from an incident is where the similarity threshold came from, and the one-token queries ('2023' vs '2024', 'not') that no threshold can catch because the embedding barely moves.

Asking a model which answer is better is one line of code. Getting a number you would let block a deploy takes position-bias control, a confidence interval, and a human-labeled set the judge is measured against. Here is the harness.

Every agent is a loop around this function. The candidates who fail it raise an exception on a bad tool call; the ones who pass hand the error back to the model as a tool result and let it fix itself on the next turn.

Every RAG system starts here, and most candidates ship the same bug: they size the chunk in characters and call it tokens. Below is running code for all four strategies, plus the infinite loop in the overlap arithmetic and the one in the recursion.

Writing the regexes takes ten minutes. The half of the question that separates candidates is the evaluation: a detector that blocks 'ignore the noise in the data' has shipped a bug to every analyst using your product. Here is the layered detector and the harness that proves it works.

This code runs on every single response, so it sits on the critical path and a heavyweight check here doubles your p95. The signal is in the ordering, the fail-open decision when the guardrail times out, and the fact that you cannot un-send a token you already streamed.

Anyone can call a rerank endpoint. The word doing the work in this question is 'prove': you have to implement DCG, ideal DCG, and nDCG@k from graded labels and report the before-and-after. Plus the ceiling nobody mentions until it bites them in production.

The naive version splits on newlines and works right up until a TCP chunk lands mid-line. Then there is the error that arrives after a 200 OK, the user who closes the tab while you keep paying for tokens, and JSON you cannot parse until it closes.

Asking a model 'is this answer hallucinated?' barely beats a coin flip. This is the build: claim extraction, a judge forbidden from using world knowledge, a denominator that excludes hedges, and one model call per claim, which decides where the check can run at all.

Everyone can write the happy path. The screen is decided by the two branches most candidates skip: what the system does when retrieval finds nothing good, and what it does when the model cites a chunk you never sent.

A prompt is code, but most teams edit it in a dashboard with no history and then cannot explain last Tuesday's quality drop. This is the small piece of infrastructure that makes prompts reviewable, pinnable, and instantly reversible.

Most RAG projects do not die at the retriever, they die at ingestion. Naive PDF extraction interleaves columns into nonsense, shreds tables, and stamps the footer into all 4,000 chunks. Here is the parser that survives real documents.

The applied data-wrangling screen: here is a grubby database, turn out 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 rather than trusting it.