hardNewOpenAIMeta

Implement dominant resource fairness for a cluster where jobs need different mixes of GPU, CPU and memory.

Fair sharing of one resource is obvious and fair sharing of three is not, because a GPU-heavy job and a memory-heavy job are not comparable. The rule that makes them comparable, the greedy loop that implements it, and the tie-breaking bug that gave one user everything.

Updated Sep 2026 · Grounded in real AI infrastructure interview loops and written to a senior-engineer editorial bar, with every number worked and every diagram hand-built.

The concepts behind this question

Ranked by how closely each one overlaps this question's topic, so the first card is the thing to read if the answer above moved too fast.

Advanced

🗂️ Scheduling & Orchestration🔒 Premium

Multi-Tenancy, Quotas and Fair ShareA shared GPU pool is cheaper than ten private ones because ten teams' demand is smoother than one team's, and it only works if the sharing is enforced. Quotas say what each team is guaranteed, borrowing lets idle guarantees be used by others, fair share decides who waits when everyone wants more, and preemption reclaims borrowed capacity. This page works the arithmetic that makes pooling worth it, the layers of isolation a tenant needs, and the incentive problems (hoarding, gaming, the research-versus-product tension) that any policy has to survive.

Core

📐 AI Systems DesignSign in

GPU Job Scheduler DesignDesign a scheduler for a shared GPU cluster is the most common design prompt in AI infrastructure interviews, because it touches everything: queues and priorities, gang placement, topology, fairness across teams, preemption and the checkpoints that make it survivable, and the failure handling that keeps a 512-GPU job alive. This page builds the design in layers, states the data model and the scheduling loop, derives the numbers (how long a job waits, how much preemption costs, how much fragmentation wastes), and lists the trade-offs the interviewer will push on.

Core

🚀 Inference & ServingSign in

Continuous BatchingContinuous batching schedules at the granularity of a single decode step instead of a whole request, so a finished sequence's slot is refilled on the next iteration rather than when the longest request in the batch ends. It is the scheduling idea that turned LLM serving from a padded, half-idle GPU into one that stays full, and it decides how the engine's scheduler, memory manager and latency SLOs interact.

Advanced

🚀 Inference & Serving🔒 Premium

Chunked PrefillA long prompt's prefill can occupy a GPU for hundreds of milliseconds, and every sequence mid-decode on that GPU waits for it. Chunked prefill splits the prompt into fixed token budgets and interleaves each chunk with a decode step, so decode latency stays flat at the cost of a slower first token for the long prompt. The chunk budget is a knob between TTFT and TPOT, and the interview question is how you would set it.

Explore the full curriculum →

UP NEXT ON YOUR JOURNEY

Next in this trackWrite a tiled matrix multiply and explain the cache effect. Then say honestly what your benchmark actually measured.Next in this trackImplement a log-structured event store for fleet metrics with range queries and compaction.Next in this trackA multi-GPU training job hangs at step 400 with every GPU at 100 percent utilization. Debug it.

FEDITOR'S NOTE

Scored on the dominant-share definition making heterogeneous demands comparable, on the greedy loop selecting the lowest current share, and on the tie-breaking error that starves a user.

DISCUSSION · 0

No comments yet — be the first to share your approach.