Yes — one round, not four, and the problems are not random. Eight that are quietly the same problems you solve when you put a model in production.
It is the first thing candidates ask about AI engineer and FDE loops, usually hoping the answer is no. The answer is: one round, roughly 45 minutes, and it is rarely the hard dynamic-programming problem you have been grinding. It is almost always a data-structure design problem — because that is what the job is. A model sits in the middle and you build the plumbing around it: caches, top-k selection, ordering, streaming counters.
Eight problems that are secretly AI-infrastructure problems
All eight are free on LeetCode and none of them are there by accident — each is the toy version of something you will build for real.
| PROBLEM | PATTERN | WHAT IT IS IN A REAL SYSTEM |
|---|---|---|
| 146. LRU Cache | hash map + doubly linked list | The eviction policy in a semantic cache or a KV-cache tier. |
| 215. Kth Largest Element | heap / quickselect | Top-k selection from a retrieval candidate set before the reranker sees it. |
| 23. Merge k Sorted Lists | k-way merge | Fusing ranked lists from hybrid search — the mechanic underneath reciprocal rank fusion. |
| 210. Course Schedule II | topological sort | Ordering tool calls with dependencies, and detecting the cycle that hangs an agent loop. |
| 295. Find Median from Data Stream | two heaps | Streaming p50/p95 latency without keeping every request in memory. |
| 981. Time Based Key-Value Store | binary search over timestamps | Versioned agent memory: what did the agent know at 14:02, before the tool call? |
| 3. Longest Substring Without Repeating Characters | sliding window | The window-with-overlap primitive every chunking strategy is built on. |
| 208. Implement Trie | prefix tree | Prefix lookup — tokenizer vocabularies, tool-name routing, autocomplete over a doc set. |
Solve it, then keep going for five more minutes: say out loud what breaks at 10M entries, what changes when four replicas share the structure, and what you would measure to know it is working. That second half is the part nobody rehearses, and it is the part that is scored.
What they don’t ask
Hard dynamic programming, obscure number theory, and anything that hinges on a trick you either know or don’t. The bar is fluency, not puzzle-solving — you should reach for the right structure without ceremony and then talk about it like an engineer who has been paged before. If you are grinding a 300-problem list for one of these loops, you are optimising the wrong thing.
The round that actually decides the offer is the other one — the messy customer scenario. That is covered in the FDE interview post.