deployment

Prompts are production code that nobody treats like code, until an innocent one-line tweak tanks accuracy. The version-eval-canary-rollback pipeline that AI-native interviewers expect by default.

Every eval question in the prep canon is about answer quality. This agent does not produce answers, it moves freight. You cannot score a reroute for faithfulness, and the candidate who tries has not understood what they built.

Offline wins don't justify big-bang swaps, models fail in ways staging never shows. The shadow → canary → ramp playbook, what to compare at each stage, and the rollback discipline that keeps customer trust.

The capstone panel question that ties the whole track together. The spine, data, training, deployment, monitoring, operating model, plus the maturity-staging judgment that separates architects from slide-readers.

Everyone spots that the customer records need resolving. The failure that actually sinks this project is quieter: the word fraud means three different things in the three datasets, so the union of their labels trains a model that is confidently wrong.

This isn't a deployment question, it's a judgment question wearing one. Interviewers are scoring whether you have a decision framework, a safety checklist, and the spine to say no to a customer politely.

Prompts are production code with a worse failure mode: the regression returns 200 OK. The answer interviewers reward treats a one-word prompt edit with the same machinery as a schema migration, with one LLM-specific twist at every stage.

API keys for systems you don't own, in environments you can't always reach, audited by security teams who don't trust you. The strong answer has one organizing principle, and a concrete story for rotation and the air-gapped case.

The defining Palantir-style deployment question. Everything your laptop did silently (package pulls, API calls, telemetry, auth callbacks, clock sync you never thought about) becomes a named workstream. Strong answers produce the checklist by category, not by anecdote.

The pattern is expand-contract; the interview is everything around it: the backfill that locks the table, the rollback nobody rehearsed, and the fact that it's the customer's database, not yours. One named technique carries the whole answer.

The question that defines forward-deployed engineering as a discipline: production you're responsible for but can't touch. The answer is a system (version skew, telemetry tiers, diagnostic bundles, release trains), not a collection of favors from customer IT.

No data leaves, you cannot pre-inspect the corpus, and your toolchain arrives on a single USB. Design adaptation and evaluation when you will never observe a single input or output.

The obvious engineering answer is to rewrite the notebooks properly and schedule them. Do that and you will have built something correct that the people who own the work can no longer maintain.

Every instinct says move fast. The arithmetic says otherwise: eight hours of preparation reached a fixed system 26% sooner than shipping immediately, because each failed attempt costs a two-day approval cycle and you only get one shot per cycle.

The deployment worked. The software runs, the data flows, the demo landed. Nobody is using it. Two of the three research sets we vetted surfaced this from different angles, and it is the failure mode that ends renewals.

Nothing about the software changed. The single person whose belief the contract rested on is gone, and the replacement has more to gain from cancelling your project than from finishing it.

The trap is that it looks like a prioritization problem you can solve with a scoring rubric. You do not have the authority to rank these people's work, and the moment you try, you have made yourself the obstacle.

The question that separates a forward deployed engineer from a very good consultant. One delivers each engagement. The other notices that the third engagement looked like the first two and does something about it.

They answer different questions, and mixing them up costs you the round: one tests your engineering, the other tests your model's business impact. What each can and cannot catch, and the order a strong candidate always runs them in.

A real interview question designed to catch resume inflation: candidates say 'we promote to production' and can't name the API call. What actually moves when a model is promoted, and the answer that proves you've done it.

Reported from Capital One ML loops, and the symmetric 'both have pros and cons' answer fails it. Why model failures being statistical makes canary the default, the two cases where blue-green wins, and the entity-randomization detail that survives follow-ups.

Reported from JPMorgan's MLE loop, and graded on one distinction most candidates miss: rollback is a capability you build before the incident, not an action you improvise during it. The pointer-flip mechanics, the auto-trigger debate, and when rollback itself is unsafe.

'Can't leave our environment' means four different things to four different stakeholders. The FDE skill is decomposing the demand into the actual requirement, and knowing which deployment tier each requirement really needs.