Coding & DSA Interview Questions for AI Engineers

The most common screen opener, and interviewers use it to check whether hashmap thinking is reflexive. Here's the one-pass answer, the narration that earns points, and the duplicate-handling edge case most candidates fumble.

A 5-minute warm-up that quietly tests the most useful idea in practical coding: choosing a canonical key. The sorted-string vs character-count tradeoff is exactly what interviewers want to hear you reason about.

The interval pattern shows up everywhere in FDE loops: calendars, flight segments, log windows. Master the sort-then-sweep idiom here and three other interview questions fall out for free.

The follow-up interviewers reach for when merge-intervals goes too smoothly. The three-phase scan is elegant, but only if you've internalized the overlap condition most candidates have to re-derive under pressure.

Top-K is the most reused primitive in FDE interviews: it reappears inside log parsers, analytics questions, and retrieval ranking. Three solutions exist; knowing which one to lead with is the real test.

Looks like a sliding-window problem; isn't one. The prefix-sum + hashmap trick that solves it is the same idea behind sessionization and cumulative-metrics questions later in the loop: learn it once, reuse it three times.

The gentlest 'design a class' question in FDE screens, and the warm-up interviewers use before rate limiters and sessionization. The deque trick is easy; the API and time-window follow-ups are where the signal is.

Anthropic-style screens open with deceptively simple builds like this, then extend them three times. The grade isn't the counting; it's whether your first version survives the extensions without a rewrite.

Everyone knows the sort + two-pointer outline. The interview is actually about duplicate handling: three separate skip conditions that candidates routinely botch live. Here's the clean version and the narration that goes with it.

The single most-asked design-a-data-structure question in FDE loops. There's an interview-legal Python shortcut and a from-scratch version, and knowing when to offer which is half the grade.

K-way merge is the algorithm behind log aggregation, search-result merging, and LSM trees, which is exactly why FDE loops keep asking it. The heap version is table stakes; the tie-breaking detail is where candidates crash.

The canonical grid question, and the template for every flood-fill, shortest-path, and region-labeling variant FDE loops throw at you. BFS vs DFS vs union-find: here's which to write and which to merely mention.

The follow-up to number-of-islands, and the question where candidates reveal whether they understand WHY BFS finds shortest paths. Plus the two variants (weights, eliminating obstacles) that decide hard-screen outcomes at xAI.

The third member of the grid trilogy, and the one that tests backtracking discipline: marking, unmarking, and the early-exit pruning that turns a timeout into a pass.

A tree question that's secretly a format-design question, which is why FDE loops love it. The preorder-with-null-markers trick is clean, but the delimiter and malformed-input follow-ups are where offers are decided.

The Palantir coding-screen classic. It looks like merge-intervals but needs a different weapon, the sweep line, and the boundary-tie detail decides whether your answer is right or off by a planeload.

The quintessential FDE practical: messy real-world input, grouping, ranking, and a hidden rubric line for how you treat malformed data. Most candidates parse happily and lose the round on the lines that don't parse.

Sessionization is the analytics primitive behind every 'how do users actually behave' question, and a favorite practical screen. The algorithm is easy; out-of-order events and duplicates are where the round is actually scored.

Every data migration at every customer site needs this exact tool, which is why Palantir and Retool keep asking it. The diff is a dict comparison; the grade hides in keys, duplicates, and column drift.

A multi-part favorite at OpenAI-style screens: simple store, then time travel, then deletes that don't actually delete. The append-only insight plus one bisect call solves the whole thing, if you set up the invariant correctly.

A verbatim-reported multi-part at OpenAI and Anthropic. Each level breaks the previous design on purpose: the burst-at-the-boundary flaw is planted, and naming it before the interviewer does is how you win the round.

The format that filters out LeetCode-only candidates: unfamiliar code, failing tests, 45 minutes. There's a repeatable protocol for it, and a reason the first five minutes decide the round.

The coding question that doubles as a RAG-fundamentals check. Greedy packing is easy; the oversized-sentence case, the overlap-progress trap, and the tests you write unprompted are what AI-lab interviewers actually score.

The question where production scars are the rubric. Anyone can write a retry loop; the grade lives in which errors you DON'T retry, why jitter exists, and what an idempotency key actually protects you from.

Palantir's bread and butter: 'Acme Corp.' and 'ACME Corporation, Inc.' are the same customer; prove it in code. Normalization does more work than the clever algorithm, and blocking is what makes it run before the heat death of the universe.

A three-level build that quietly tests whether your L1 design survives L3. Regex substitution wins level one and loses the round; here's the token-based structure that carries through conditionals and loops.

Exact-match pub/sub is a dict of lists. The round is decided at level two (wildcard matching on hierarchical topics) and at level three, when the interviewer asks what happens when a subscriber's callback throws.

Kahn's algorithm gets you level one. The round is won at level three, where 'run up to K tasks at once' breaks naive topo sort, and the indegree bookkeeping you chose at L1 either saves you or sinks you.

The practical build that's secretly a graph problem: formulas are a dependency DAG, evaluation is DFS with memoization, and the three-color cycle trick decides whether A1=B1, B1=A1 crashes you or earns the offer.

The OpenAI FDE signature question, reported near-verbatim for two years: four levels in ~60 minutes, where L4 silently breaks every naive L3 implementation. The lazy-expiry design that survives all four levels, with the pacing plan.

The other OpenAI signature build, reported in four parts for two years. Part C silently punishes anyone who hardcoded single-condition filtering in part B; here's the predicate-compiler design that absorbs all four parts.

An OpenAI bank regular: next() over a list, then save/restore position, then resume across multiple JSON files where some are empty. The whole question is one decision (what counts as state) and most candidates get it wrong on part one.

cd('/foo/bar', 'baz') is easy. cd('/foo/../', './baz') is where the OpenAI screen actually starts, and the symlink follow-up is where it ends. The stack solution plus the loop-guard most candidates forget.

The OpenAI variant where the data structure is the warm-up: the round is graded on whether your tests control time and whether you can argue global vs per-key vs optimistic locking with actual reasons. Most candidates ace part one and lose the round in parts two and three.

A reported OpenAI build that looks like billing and is actually a data-structure question in disguise: credit grants that expire, usage that must burn the right grant first, and balance queries at arbitrary times. The earliest-expiry-first invariant carries the whole problem.

No JSON libraries allowed, and the test data contains commas, newlines, and your escape character itself. Length-prefix encoding solves it in fifteen lines, and knowing why it beats escaping is the actual interview.

A confirmed Anthropic live-coding question that looks exotic and reduces to one operation: diff consecutive call stacks against their common prefix. The recursion edge case is where strong candidates separate from finished-but-wrong ones.

Anthropic's reported twist on the LRU staple: the cache is a decorator, the keys are arbitrary call signatures, and the follow-up writes it to disk. The kwargs-ordering and unhashable-argument traps are the whole interview.

The reported Anthropic concurrency round: the crawler is twenty minutes, the follow-ups are the interview. Why threads work despite the GIL, what asyncio buys you, and where the semaphore goes. The answers, with the race condition graders plant.

Palantir's signature coding genre isn't an algorithm; it's working from unfamiliar documentation: a graph API, a custom serialization spec, a mini query language. The behaviors graders score, plus the BFS-over-an-opaque-client worked example.

The reported ElevenLabs live round, written in a shared Google Doc, no execution, no autocomplete. Inherited folder permissions plus permission-change timestamps, and the two-axis resolution rule that keeps the code to thirty lines.

C3.ai runs the most LeetCode-classic FDE loop, and candidates report the same published set for years: Trapping Rain Water on the phone screen, Daily Temperatures in the tech screen. Both optimal solutions, plus the one-line insight that unlocks each.

The build behind every access policy and routing rule a customer wants to edit without a deploy. The trap is operator precedence: candidates who tokenize fine still get `a or b and c` wrong, and that's the whole grade.

The retry loop's grown-up sibling. Retries protect one call; a breaker protects the whole dependency from a retry storm. The grade is in the half-open state, where letting through one probe instead of all of them is the difference between recovery and re-killing the server.

At-least-once delivery means duplicates are guaranteed, not hypothetical. Anyone can use a set; the round is whether your set grows forever, and what you do with an event that arrives after its window closed.

A 10% rollout where the same user flips on and off between requests is worse than no rollout. The whole problem is determinism: hash the user into a stable bucket so ramping 10% to 25% only ever adds users, never reshuffles them.

Executing a query is the easy half; deciding HOW to execute it is the staff-level half. The interesting failure is choosing an index that returns 90% of the table, where a full scan is genuinely faster, and a planner that knows that beats one that always uses the index.

Sliding-window limiters count requests; an API that bills by tokens needs to reserve a variable cost up front and refund it if the call fails. The trick is lazy refill: never run a timer, compute the current balance from elapsed time on each check.

Google's FDE loop added an AI-first round, and this is the opener. The skill being graded is not prompting, it is decomposition: turning a fuzzy sentence into scoped units with named interfaces an assistant can one-shot. Get the seams wrong and no prompt saves you.

The naive fix is to nag the model in every prompt. The staff move is to treat your constraints as a versioned policy library injected as system context, so compliance is structural, then verify it with a linter because prompts are advisory, not enforced.

When the model writes the code, your job shifts to specifying and checking it. The strong answer is a multi-layer validation pipeline that tests behaviors and contracts, not strings, plus the uncomfortable reframe that testing is now the bottleneck skill, not typing.

You can't read the model's weights, so you debug the inputs you control. There's a four-bucket triage, prompt, context, model, or spec, that localizes the fault fast, and the real deliverable is feeding each diagnosis back so the same failure can't recur.

AI code fails differently from human code: it's confidently plausible. The dangerous defects are the ones that pass a quick read and a happy-path test, missing authorization, hallucinated APIs, hardcoded secrets, unsafe deserialization. Here's the checklist and the automated catch for each.

If you read every AI PR line by line, you become the throttle the assistant was meant to remove. The staff answer is a risk-tiered trust model: route by blast radius, let gates clear the low-risk volume, and spend human attention only where reversibility is low.

The function reads a file, parses it, computes a metric, and prints, all tangled together. The move interviewers want is not prettier code, it's pulling pure logic out from side effects so each piece can be tested in isolation.

Brute force is O(N*d) per query and dies at ten million vectors. The answer is approximate nearest neighbor: trade a little recall for orders of magnitude less work, and know exactly which knob buys what.

A classic FDE take-home shape: messy real documents in, structured index out. The grade is in the seams between reader, extractor, and writer, and in what happens when one file is garbage.

Everyone quotes p95 in latency SLOs, but few can compute it without a library and fewer can explain why the index is ceil(p*n)-1, not p*n. The warm-up that screens whether you actually understand the metric you live by.

The arithmetic is three sums; the signal is what you do when a vector is all zeros and the denominator vanishes. The warm-up that gates every RAG and retrieval coding round.

Real LLM logs are JSONL, not JSON, and real log files have a malformed line halfway through. The warm-up that screens whether you can stream a file and aggregate without one bad record nuking the whole run.

Batching inputs is how you keep a GPU fed, but the source is an iterator you cannot index or len(). The warm-up that screens whether you can write a lazy generator that handles the ragged final batch.

A dashboard needs the average tokens/sec over the last N seconds, updated on every sample, forever. The warm-up that screens whether you evict by time and keep a running sum instead of re-summing the window each call.

Every classifier and every LLM-as-judge eval reduces to a confusion matrix, but the screen is whether you handle the zero-denominator cases without crashing and can say which metric matters for the problem at hand.

Every chat model decodes with top-p, but few candidates can build it from logits: softmax, sort, take the smallest set of tokens whose cumulative probability crosses p, renormalize, sample. The screen for whether you understand decoding, not just call an API.

The loss every language model trains on, built from logits with no torch in sight. The screen for whether you understand log-softmax and the numerical-stability trick, not just import nn.CrossEntropyLoss.

BPE is how GPT and most LLMs turn text into tokens, and building a tiny trainable version from a corpus is a favorite deep-dive. The screen for whether you understand the merge loop, deterministic tie-breaking, and round-trip decode, not just tiktoken.encode.

All-pairs comparison is O(n^2) and dies long before 1TB. The senior move is MinHash plus LSH: hash documents so only likely-similar pairs ever land in the same bucket, then verify just those.

The assign-then-update loop is ten lines; the signal is whether you handle the three things that bite in production: initialization, an empty cluster, and a real convergence test instead of a fixed iteration count.

There is no training, just storage; the work is at query time. The signal is whether you vectorize the distance computation, break ties sensibly, and know when O(n) per query forces you onto an ANN index instead.

softmax(QKᵀ/√d_k)·V in four lines, but the grade is the three details people drop: the √d_k scale, subtracting the row max for numerical stability, and getting the causal mask to add -inf before the softmax, not after.

The whole question is the representation: store only the nonzeros as index→value, then either two-pointer over sorted indices or hash-join. The follow-up that decides the design is what happens when one vector is dense.

An ML coding screen that doubles as a calculus check. Interviewers watch whether you can write the MSE gradient without looking it up, explain what the learning rate actually does, and say out loud when you'd just solve the normal equation instead.

A DP classic that screens for one thing: can you define the right subproblem and fill the table without fumbling the indices. The strong version adds the O(min(m,n)) space trick and reconstructs the actual edits when the follow-up lands.

Almost everyone reaches the O(n²) DP. The signal interviewers want is the O(n log n) patience-sorting trick, plus the honesty to say the array you build along the way is not itself the answer subsequence.

The question that punishes greedy. Interviewers pick denominations where taking the biggest coin first gives the wrong answer, and they watch whether you reach for DP and handle the impossible-amount case cleanly.

The classic linear DP. At each house you either skip it and keep the best so far, or take it and add the best from two back. The signal is collapsing the table to two rolling variables and then handling the circular follow-up cleanly.

A sliding window with a last-seen index map, O(n) in one pass. The whole interview turns on one subtlety: when you hit a repeat, the window's left edge must jump forward and never slide backward, which is exactly the bug most candidates ship.

Build the output from prefix products on a left-to-right pass, then fold in suffix products on a right-to-left pass using the output array itself as scratch. O(n) time, O(1) extra space. The interesting part is why division is banned and what it costs when the input has zeros.

The O(log(min(m,n))) answer binary-searches a partition on the shorter array so the left halves of both arrays together hold exactly half the elements. The whole problem is one invariant plus careful boundary handling for empty sides and odd versus even totals.

A sorted array got rotated at an unknown pivot and you still have to find a target in O(log n). The trick is deciding which half is sorted at every step. Here's the clean invariant, and the duplicates follow-up that quietly breaks the log-n promise.

Almost everyone writes the version that only compares each node to its immediate children, and almost every interviewer has a counterexample ready. The fix is to carry a valid (low, high) range down the recursion, or to check that an inorder traversal is strictly increasing.

The longest path between any two nodes need not pass through the root, which is what trips people up. The clean answer is one DFS that returns each node's height while updating a global best as it goes. First, nail down whether diameter counts edges or nodes.

A path can start and end anywhere and bends through at most one node, values can be negative, and you want the maximum sum. The move is a DFS that returns the best downward gain (clamped at zero) while a global max tracks the best path that bridges through each node.

The clean answer hinges on one insight: preorder names the root, inorder splits left from right. The trap is the O(n squared) version that slices arrays and scans for the root; the O(n) version uses a hashmap of inorder indices and passes bounds instead.

The tell is whether you avoid the trap of sorting all n points when you only need k. Two real answers: a max-heap of size k at O(n log k), or quickselect at O(n) average. Knowing which one the interviewer wants is the actual question.

A full sort throws away the structure you were handed. Because no element moves more than k slots, a min-heap of size k+1 always has the next smallest element on top, sorting in O(n log k) and one pass.

A two-part screen that looks like a warm-up and isn't. Part one is the classic stack validator with three bracket types; part two flips to generating every valid string of n pairs, and the Catalan count is the detail that catches people off guard.

You have a coin that lands heads with some unknown probability p. Build a fair 50/50 flip from it without knowing p. The von Neumann trick is two lines; the part that scores is explaining why the bias cancels and how many flips it costs.

A grid where some cells start infected, and each step every infected cell infects its orthogonal neighbors. How many steps until everything is infected, or -1 if some cell is unreachable? This is rotting oranges in disguise, and the multi-source BFS framing is what they want to hear.