AI Infra Coding Interviews Are Not LeetCode: What They Ask Instead

If you are preparing for AI infrastructure coding rounds by grinding array puzzles, you are preparing for the wrong interview. Some screens do include a LeetCode medium and you should be able to clear one, but the rounds that decide outcomes look different. A CoreWeave candidate describes the first technical round as a non-LeetCode style question on implementing concurrency in Go. An NVIDIA candidate describes the onsite as not much LeetCode, but you need to be an expert in the team's working domain. OpenAI reports describe implementation-heavy progressive challenges. The named problems that recur are recognisable and they are all the same species.

The problems that actually get asked

A sliding-window rate limiter. Allow N requests per window per key. There is no trick. There is a design choice between a fixed window (cheap, wrong at the boundary, where a client can send 2N requests across two adjacent windows), a sliding log (exact, memory proportional to request count), a sliding window counter (approximate, cheap), and a token bucket (smooth, handles bursts naturally). The round is about naming the trade and then handling the boundary case the interviewer asks about next.

A time-based key-value store. Set a key with a timestamp, get the value as of a timestamp. The core is a sorted structure per key with a binary search on read. The follow-ups are where it lives: what about deletes, what about memory growth, what about concurrent writers.

A resumable iterator over a large dataset. Iterate, and at any point produce a token that lets a new process continue where you stopped. This one is genuinely infrastructural: the answer forces you to think about what state is and is not serialisable, and about what happens if the underlying data changed between the two runs.

A ledger with multiple transaction types, progressive. Anthropic's widely reported CodeSignal screen is this shape. Part one is trivial. Part four adds something like scheduled transfers or merged accounts, and a dictionary of balances turns out to be the wrong model.

Concurrency implementation, especially in Go at CoreWeave. A bounded worker pool, fan-out with cancellation, timeouts that clean up properly.

Scheduling and interval problems with real semantics. Allocate GPUs to jobs, merge reservations, compute utilisation over a window. These sit right at the boundary between coding and design, and our cluster and orchestration questions cover the domain they draw on.

Our practical coding track is built entirely on these shapes.

Why progressive problems break people

The format is the same everywhere: part one is easy, and each subsequent part adds a requirement. It looks generous. It is a trap for anyone who optimises part one.

The specific failure: you write the clean minimal solution for part one, it works, you feel good, and then part three needs history and your structure has been overwriting values in place. Now you are rewriting under time pressure with an interviewer watching.

Two defences, both cheap.

Ask what is coming. "Is there likely to be a part two that changes the data model?" Almost every interviewer running a progressive problem will give you a useful answer, because they are not trying to trick you, they are trying to see how you build. Very few candidates ask.

Default to the slightly-too-general structure. In this genre it is almost always right to store a list of events rather than a current value, to key by an object rather than a primitive, and to leave a seam where a policy might change. It costs you two minutes at the start and saves the rewrite.

What is being scored

Does it work, including the boundaries. Empty input, single element, the window edge, the concurrent case. Say the boundary out loud as you handle it.

Did you make a choice, and can you defend it. These problems have several correct answers with different trade-offs, unlike a puzzle with one. The interviewer wants to hear "I am using a token bucket because bursts are normal here and the memory is constant, at the cost of not being exact about any specific window."

Complexity, stated without being asked. Both time and memory. In infrastructure rounds memory is often the more interesting one, because the data does not fit.

Production sense. This is the differentiator at senior level and it is almost never asked for explicitly. Two sentences, unprompted, on each of: what happens when this process restarts, what happens when there are twelve replicas of it, what you would log or emit as a metric, and what happens under a burst ten times larger than expected. Our reliability and observability track covers the thinking behind those answers.

Tests. Write a couple, and name the ones you would add.

How to practise

Twenty problems, not two hundred. Pick from the list above and its neighbours. Depth beats coverage here because the space of shapes is genuinely small.

Always add a second part yourself. Solve the rate limiter, then make it distributed across replicas. Solve the key-value store, then bound its memory. Solve the worker pool, then add cancellation and a timeout. This trains the exact muscle the format tests.

Time yourself at 30 minutes for the core, leaving room for follow-ups. Reported advice from candidates who passed these loops is to practise implementation-heavy problems under 30 minutes rather than to broaden coverage.

Write in the company's language. If CoreWeave, write Go until goroutines, channels, context and select are automatic. If OpenAI or Anthropic, Python. If NVIDIA systems, C++, and spend an hour on move semantics and object lifetimes, which candidate reports mention repeatedly at the phone screen.

Narrate while you type. Every one of these rounds is scored on your explanation as much as your code, and narrating is a skill that degrades under pressure unless you have practised it.

The one-line summary

LeetCode asks you to find a trick. Infrastructure coding asks you to make a decision and defend it, then survive a requirement you did not plan for. Practise the second thing.

Start with the practical coding questions, and browse the full question bank for the domain rounds that sit alongside them.