How long does the inference readiness assessment take?

Roughly a quarter of an hour: 4 short questions on your target role and timeline, followed by 17 scenarios shaped like the prompts serving and kernel interviewers give.

Does it score my ability?

No score is produced. Picking an option says nothing about whether you can make a kernel fast on real hardware, so the output is a map of which of the twelve rounds you have hands-on exposure to, and the plan targets the rounds where that exposure is thin.

Do I need an account?

No sign-up is required to take it, read the diagnosis or open the whole plan. An account only stores the plan and tracks progress against it between visits.

What does an inference engineer interview test?

Inference physics and rooflines, KV cache and GPU memory, batching and scheduling, attention kernels, GPU performance, quantization, speculative and constrained decoding, distributed inference, serving engine internals, serving system design, performance debugging and implement-from-scratch coding. The system design round and the implementation round most often decide level.

Free · No account needed · About 15 minutes

How ready are you for an inference interview?

17 scenarios written the way serving, kernel and fleet interviewers phrase them. At the end you see which of the twelve rounds you have real exposure to, the single gap most likely to sink a loop, and the pages that close it. Each option you pick is explained as an interviewer would read it, so a half-finished run still teaches something.

About you0%

Which role are you going for?

Kernel, serving and ML systems roles share vocabulary but grade on different rounds.

The twelve areas an inference loop tests

Every inference loop draws from this list. The mix shifts by employer: an accelerator vendor leans on kernels and numerics, an inference provider on scheduling and fleet cost, a trading firm on tail latency. The scenarios above sample all twelve.

Inference physicsdecides loops: The cost model every other round assumes. A candidate who cannot price a decode step in bytes gets the remaining questions wrong for the same reason.
KV cache & memorydecides loops: Where model architecture becomes serving cost. Concurrency, context length and preemption are all decided by the KV budget before any kernel runs.
System designdecides loops: The round that sets level. It rewards designs derived from tokens per second and dollars per token, and it exposes designs drawn from a template.
Implementationdecides loops: Most loops ask you to build a piece of an engine by hand. Graders test the invariants and the edge cases, not whether the happy path runs.
Batching & schedulingexpected: Throughput and tail latency are decided here. Knowing why iteration-level scheduling won is table stakes; pricing the token budget is the signal.
Serving enginesexpected: Teams expect you to know which component owns each decision in the engine they run, as of a recent version, not as a 2023 paper described it.
Performance debuggingexpected: A regression with partial evidence is a common round. It grades the order you ask for metrics in more than the final answer.
Quantizationexpected: Every serving decision now involves a number format. The question is never whether to quantize, but which format wins at which batch size and on which GPU.
Attention kernelsexpected: FlashAttention is the most asked kernel topic, and the most often explained wrong: it changes bytes moved, not FLOPs.
GPU performanceexpected: Central for kernel and performance roles and present everywhere else as profile reading. Bytes in flight and grid coverage explain most slow kernels.
Distributed inferenceexpected: Any model above one GPU raises it. The trade-off between tensor parallelism and replicas is a staple question with a counter-intuitive answer.
Decoding algorithmssituational: Speculative decoding is asked often and understood rarely. The algebra is short; knowing when it stops paying is what interviewers remember.

Profiles this tends to find

Instead of a percentile, the diagnosis gives your answers a profile. Six of the common ones are below; each points to a different first week of study.

The Kernel Engineer Who Has Not Met the Scheduler
Your answers on memory hierarchy and kernels are the answers of someone who has profiled real code. Then the engine and fleet questions land differently: you optimize the step you are given, where the round is asking what shape of step the scheduler should produce and how many replicas the load needs.
The Systems Engineer Without the Cost Model
You think in queues, replicas and failure domains, which is most of the fleet round. What is missing is the unit of cost underneath it: a decode step priced in bytes, a prefill priced in FLOPs.
The Theorist Who Needs Reps
You know the mechanisms: the roofline, the formats, the speculative decoding algebra. The gap is the two rounds that test doing rather than knowing: writing an allocator or scheduler under time, and debugging a regression from partial metrics.
The One Who Prices the Cache
Unasked, you priced the KV cache in bytes and checked the HBM bandwidth floor before proposing anything. Panels read that habit as the clearest sign of a serving engineer.
The Strong Generalist
No round came out thin. That makes preparation harder to aim, and the usual result is rereading familiar material.
Early, and Aimed at the Right Thing
You have not yet served a model someone else depended on, and loops probe that experience indirectly in every round. The good news is that the core of this field is a small set of mechanisms with arithmetic attached, and those can be learned in weeks..

Where the plan sends you

Every plan links into the pages below. Skipping the diagnostic and reading directly works too.

Why not just ask a chatbot?

Try it. For a first overview of what serving interviews cover, a chatbot does fine. Where it falls short for loop prep comes down to four specific gaps.

It will agree with you

Propose tiling a batch-1 decode GEMV through shared memory and a chatbot will often praise the idea. This diagnostic marks it wrong and shows why: each weight byte is read exactly once, so staging buys no reuse and the kernel stays bound by HBM bandwidth. Options carry weights set by how a panel would react, including when the reaction is no.

It only covers what you bring up

A prompt can only name topics you already suspect are weak. Candidates who prepared for kernels rarely think to ask about preemption policy or NCCL all-reduce cost, and those are the rounds that surprise them. The scenarios here sample every one of the twelve, including the ones you would skip.

Its reading list points nowhere specific

"Review KV cache sizing" is advice. Here that line becomes a link to the concept page with the byte arithmetic and to the interview questions that probe it. Each step in the plan maps to a page on this site: 196 questions with worked answers and 36 concepts, plus 12 lessons.

The conversation does not persist

A month from now that chat thread is buried. The diagnosis here is recomputed from your stored answers, so it reads the same each visit and its links resolve to live pages. With an account it is kept for you.

Chatbots explain FlashAttention tiling or paged KV well, and you should use them for that. Finding your gaps is a separate task: it takes the same fixed set of scenarios for every candidate, answer weights tuned against how panels grade, and material to send you to.

Why this measures coverage and not ability

Choosing the right option about warp divergence does not show that you can profile a kernel in Nsight Compute and fix it, and inference engineers would see through a page that claimed it did. So there is no 0 to 100 rating. The output lists which rounds your choices suggest you have practiced, a claim a fixed scenario set can back. A named gap gives you a next page to read; a percentage gives you nothing to open.