The AI Engineer Case-Study Round: How to Pass the Stage That Decides It

The AI engineer case-study round is the stage that decides your loop, and you pass it by scoping before you architect. You get an ambiguous product goal, and your score comes from how you bound it: who the user is, what decision the model's output drives, what a wrong answer costs, what data already exists, and what is explicitly out of scope. Only then do you pick a lever (prompting, retrieval, or fine-tuning), define the eval, and name how the thing fails. This round is where strong coders lose most often, usually by hearing two sentences and jumping to an architecture. The winning shape is a sequence, and everything below expands on it.

Why this round is hard

Most technical interviews reward a fast route to the right answer. This one rewards the opposite instinct, which is exactly what trips people up. It exists because building AI products is mostly ambiguity: a PM shows up with "make search smarter" or "reduce support load with AI" and no spec, and the engineer worth hiring is the one who can convert that into something buildable and measurable.

The failure pattern rarely changes. A candidate catches a domain word, "support," "search," "summarize," and within thirty seconds is drawing boxes. The interviewer is now stuck following a solution to a problem nobody has defined. The round slips away right there. The remedy holds everywhere: shrink the problem before you build anything bigger.

Scope before you architect

Give your opening minutes to making the problem smaller. The questions worth asking are about the user and the decision, not the tech stack. Who actually uses this, and what action does the output trigger. What does a wrong answer cost, and what is the volume. What data already exists, who owns it, and how good is it. What counts as success, and by when. What is deliberately left out of a first version.

Ask these out loud and let the answers reshape your plan. The goal is not to look thorough. It is to expose the one or two constraints that genuinely steer the design, because a feature bound by a strict cost-per-request ceiling and one bound by a two-second latency budget need different systems even when the surface problem sounds the same. Interviewers grade your questions before they grade your architecture. Work through the ML system design set to build that instinct, and see the questions that decide the round for how the same judgment gets probed elsewhere in the loop.

Prompting, RAG, or fine-tuning: name the missing thing first

This is the technical core of the round, and most candidates get it backwards by naming a technique and then justifying it. Do the reverse. Diagnose what the base model is missing, then pick the lever that supplies it.

• Missing facts. The model does not know your documents, your tickets, your product catalog. That is retrieval. Start with RAG.
• Missing format or behavior. The output is right but the shape is wrong, or it will not follow the policy you need. Try prompting and few-shot examples first. Fine-tune only when prompting visibly plateaus and you have enough labeled examples to make it worth the training and serving overhead.
• Missing capability. The model simply cannot do the reasoning the task requires. No amount of context or fine-tuning rescues that. Change models, or change the task.

Say the diagnosis before the choice. "The base model already writes good replies, it just does not know this customer's plan or their past tickets, so the gap is facts, not behavior, which points at retrieval" is a full senior answer in one sentence. The RAG and agent design set covers the follow-ups the interviewer holds in reserve here, and the LLM and GenAI fundamentals cover the fine-tuning tradeoffs you will be pushed on.

Scope an MVP that works end to end

With the problem bounded and the lever chosen, propose the minimal version that delivers the core outcome from input to output, then say how you would grow it. Resist listing every component of an ideal system. A workable MVP plus a believable order of what comes next reads as someone who ships. A sprawling architecture with no priorities reads as someone who has never trimmed scope against a deadline.

Concretely: name the smallest thing that produces the decision the user needs, name the model and the retrieval approach you would start with and why, and say what you would measure to confirm it works. On a retrieval-heavy problem that usually means a basic chunk-embed-retrieve pipeline over the existing corpus before anyone talks about fine-tuning, with an eval set built from real queries. Push caching, reranking, multi-tenancy, and the agent loop into the "then I would" tier.

Define the eval before you defend the design

The piece most candidates skip is how they would know the system is right. Do this before the architecture is finished, not after. Name the metric that maps to the actual decision rather than a generic accuracy figure: for retrieval, recall at k on a labeled query set; for a generation feature, a rubric-scored sample plus a groundedness check; for a classifier, precision at the operating threshold the business cares about.

Then say what score would justify shipping and how you would catch regressions as the data and the model drift. Include the unhappy cases: the queries that should return nothing, the ambiguous ones, the ones that have already gone wrong. Tie the eval back to the cost-of-error you clarified at the start. Cheap wrong answer, lighter system with spot checks. Costly or unsafe wrong answer, human review and a tighter eval loop from day one.

Name the failure modes before they ask

Close by volunteering how it breaks. Retrieval returns plausible but wrong context and the model confidently grounds on it. The corpus goes stale and nobody notices. The agent loops and burns the budget. Latency blows the p95 the moment reranking is added. Cost per request looks fine at pilot volume and ugly at ten times that.

Naming these unprompted is the strongest signal you can send, because it proves you have run one of these systems and not just read about it. Pair each with the mitigation you would actually build: a groundedness check, a freshness job, a hard loop bound, a cached path for the head queries.

The structure to carry in

Under pressure, lean on the sequence: scope the user and the decision, diagnose what the model is missing, pick prompting, retrieval, or fine-tuning to match, propose the MVP end to end, define the eval and the ship bar, then name the failure modes. Narrate each step so the interviewer can follow you, and treat their pushback as the requirements changing, which is exactly what real product goals do.

Then run it on real problems until the scope-first reflex beats the architect-first one. Start with the must-know set, drill ML system design, and practice aloud with a partner playing a PM who answers your questions vaguely on purpose. The round is not checking whether you can design a system. It is checking whether you can find the real problem before you try.