17.3 — Technical Question Bank and Final Study Guide

1. What is it, and why does this chapter look different from the rest of the book

Every other chapter in this handbook follows the 20-point structure promised in 00-front-matter/01-how-to-use.md. This one deliberately doesn't — it's a reference and self-test tool, not a topic chapter, so it trades that structure for something more useful at this point in your reading: a fast, organized way to find gaps across everything you've read, with enough of an answer key to self-check without re-reading 108 chapters cover to cover.

A caveat before you use it: several questions below touch framework specifics (LangChain/LangGraph versions, provider pricing, exact API shapes) that their source chapters explicitly flagged as "verify against current documentation" at the time of writing. That caveat applies here too, doubly — a restated question is one step further from the original warning. If an interview question turns on an exact version number or current pricing, say so out loud and give your best understanding rather than asserting a frozen fact with false confidence (Part 17.1, section 4's exact guidance on handling uncertainty).

2. How to use this chapter

Don't try to answer all ~80 questions in one sitting. Pick a theme (section 6), attempt each question out loud, check it against the one-line core-insight hint, and if you can't get to that insight unprompted, go back to the cited chapter and re-read it — this is a diagnostic tool for finding gaps, not a substitute for the depth those chapters actually contain.

3. If you have 2 hours: the top 15 highest-yield questions

These are the questions most likely to actually come up in a real AI FDE interview, weighted toward the concepts that differentiate an AI FDE from a general AI engineer. If you can answer all 15 confidently and specifically, you are in strong shape for most real interviews, even without reviewing the full bank in section 6.

1. Why is prompt injection a structural property of LLMs, not a fixable bug? (9.1) — No hard boundary between "instruction" and "data" in the context; attention lets any token influence any output.
2. Walk through the full tool-calling request/response cycle. (3.3) — The model only ever requests a call; your code always executes it — every security property follows from this.
3. What's the precise distinction between a workflow and an agent? (3.7) — Who controls the sequence of steps: fixed code (workflow) vs. the model itself (agent).
4. Why is chunk size a genuine trade-off, not a setting with one correct answer? (3.5) — Smaller chunks = more precise retrieval, less context; larger = more context, diluted embedding specificity — must be evaluated against real data.
5. Explain the excessive-agency risk formula. (9.2) — Risk ≈ number of tools × consequence severity per tool × autonomy/lack of checkpoints.
6. Why is "a customer's stated request" not the same as their requirement? (12.1) — "We want a chatbot" is a proposed solution; discovery works backward to the actual job-to-be-done before working forward to an architecture.
7. Why can't offline evaluation alone catch every production quality regression? (6.3, 8.1) — A fixed dataset can't anticipate every real-world drift; continuous online evaluation catches what only manifests under live conditions.
8. Why must tenant isolation be audited across every layer, not just the database? (9.6) — Cache, checkpoint, and observability layers are the commonly-missed ones — one weak layer undermines correct isolation everywhere else.
9. Explain the three-factor cost equation and why stacked optimizations compound multiplicatively. (7.10) — Cost = calls × tokens/call × price/token; a 50% cut in calls and 30% cut in tokens gives ~65% total reduction, not 80%.
10. Why does pod ephemerality make durable checkpointing non-negotiable on Kubernetes? (5.3, 7.4) — Pod termination/rescheduling is routine, not rare — MemorySaver loses in-flight state on any of these normal events.
11. Why is outcome-only evaluation insufficient for agent systems? (8.1) — A correct final answer can be reached via an unsound, unsafe, or lucky process that outcome evaluation alone can't see.
12. Why should authorization be enforced in tool-execution code, never in the prompt? (3.3, 9.1) — A prompt instruction is a trained tendency, not an enforced boundary — the model can be manipulated around it.
13. Why is "we can't delete it, it's baked into an embedding" not an acceptable GDPR answer? (9.6, 10.5) — Embeddings can leak source-text information and must be treated as PII for deletion purposes.
14. Why does a customer's summary of their process understate what's needed to design against? (12.2) — Tacit-knowledge dependencies and accountability-bearing judgment steps only surface from detailed, step-by-step process mapping.
15. Why should the same architecture be communicated differently to different stakeholders? (12.3) — A VP needs business impact and risk mitigation; an engineer needs precise mechanism; compliance needs named, specific controls — the same design, three framings.

4. How real interviews actually combine these questions

Interviewers rarely ask this list as a flat checklist. A single well-run interview question usually fuses 2-3 of these together into one probing thread — for example, "design a customer support agent" (Part 11.3-style) will naturally pull in the workflow-vs-agent question (#3), the excessive-agency question (#5), and a cost question (#9) as the conversation goes deeper on one design choice. Practice noticing when a follow-up question is really asking about a different item on this list wearing a different hat, rather than treating each interviewer question as isolated.

5. Trap questions specific to technical Q&A

• "What's the current version/price of X?" — Don't guess confidently. State your best understanding and flag explicitly that you'd verify the exact number (Part 17.1, section 4). Confidently asserting a stale fact damages credibility more than an honest "I'd confirm that" does.
• "Doesn't [framework feature] just solve that for you?" — Usually testing whether you understand what a framework abstraction genuinely provides vs. what remains your responsibility (Part 4.7's entire argument: LangChain accelerates implementation, it doesn't replace authorization/validation/security judgment).
• "Why not just use the biggest/best model everywhere?" — Testing Part 3.11/7.10's cost-and-latency judgment, not whether you know bigger models exist.
• "Why would you ever choose a workflow over an agent — isn't an agent strictly more capable?" — Testing whether you understand Part 3.7's reliability-compounds-negatively-with-steps argument, not a trick about capability.

6. Full question bank by theme

Each question below carries a one-line core-insight hint. If you can't produce that insight unprompted, the cited chapter is where to go next.

Foundations (Parts 1-2)

• Why does Python's GIL not prevent high-throughput LLM-calling services? (1.1) — GIL blocks CPU parallelism, not I/O concurrency; LLM calls are I/O-bound, so async concurrency works fine under it.
• Why is idempotency a bigger concern for LLM-triggering POST endpoints than typical CRUD endpoints? (1.2) — A client retry on a slow LLM call can trigger the expensive generation twice, and possibly a downstream side effect twice.
• What happens if you call a synchronous, blocking function inside an async FastAPI route? (1.3) — It freezes the entire event loop — every other in-flight request stalls, not just that one.
• Why should a natural-language-to-SQL agent use a read-only database role? (1.4) — A model-generated query can't be fully trusted; DB-level permission is the enforced backstop, not the prompt.
• Why does pgvector let tenant filtering and semantic search compose naturally? (1.5) — Both run in the same SQL engine, so a WHERE tenant_id = ... filter and a vector ORDER BY combine in one query.
• What happens if Redis goes down, for each of: caching, rate limiting, session state? (1.6) — Cache: slower but correct (fail through). Rate limit: a fail-open/closed design decision. Session: real data loss unless durably backed elsewhere.
• Why should prompts and evaluation datasets live in version control? (1.7) — A prompt change is a behavior change to production; it needs the same diff/review/rollback discipline as code.
• What does the OOM killer do, and why might an application never log an exception about it? (1.8) — It kills the process at the OS level; the process never gets a chance to catch or log anything.
• Why is exact-match testing the wrong tool for LLM output? (1.9) — LLM output varies validly across phrasings; use evaluation (Part 8) for quality, unit tests only for deterministic logic around it.
• Why is accuracy a misleading metric under class imbalance? (2.1) — A model that always predicts the majority class scores high accuracy while catching zero of the minority class.
• Why does non-linearity matter for the meaning of "depth" in a neural network? (2.2) — Without it, stacked linear layers collapse mathematically into one linear function regardless of depth.
• Why doesn't token count map cleanly to word count? (2.3) — Subword tokenization means uncommon words, names, and non-English text often split into more tokens than expected.
• Explain self-attention using the Query/Key/Value framework. (2.4) — Each token's Query compares against every other token's Key to produce weights; the weighted sum of Values updates that token's representation.
• Why can't embeddings from two different models be compared to each other? (2.5) — Each model's vector space is shaped by its own training; distance between vectors from different spaces is meaningless.
• Why is hallucination better understood as a property to manage than a bug to eliminate? (2.6) — The model generates plausible continuations, not verified facts — grounding (RAG) and evaluation manage this; no setting turns it off.

AI Engineering Core (Part 3)

• Why does chain-of-thought prompting genuinely improve reasoning, not just verbosity? (3.1) — Generating intermediate reasoning tokens gives the model more computation to draw on before committing to an answer.
• Explain constrained decoding at the token-probability level. (3.2) — Invalid-per-schema tokens are masked to zero probability before sampling — the model structurally cannot emit them.
• Walk through the full tool-calling request/response cycle. (3.3) — See top-15 #2.
• What's the pre-filtering vs. post-filtering distinction in vector search, and why does it matter for multi-tenant correctness? (3.4) — Post-filtering can starve a small tenant of results if the global top-k is dominated by a larger tenant's data.
• Why is chunk size a genuine trade-off, not a setting with one correct answer? (3.5) — See top-15 #4.
• Why can't you directly combine raw BM25 and cosine-similarity scores? (3.6) — Different, incomparable scales; Reciprocal Rank Fusion combines rank position instead.
• What's the precise distinction between a workflow and an agent? (3.7) — See top-15 #3.
• What problem does MCP solve, expressed as M×N vs. M+N? (3.8) — One server per tool provider, reusable by any compatible client, instead of every app building custom integration per tool.
• Why is an LLM stateless, and where does "memory" actually live? (3.9) — Each API call is independent; every form of memory is explicitly engineered by the application, not native to the model.
• Why might a general multimodal LLM be insufficient for a precision-critical visual task? (3.10) — General capability isn't the same as validated, benchmarked precision for a specific high-stakes measurement.
• Explain the capability/latency/cost trade-off in model selection. (3.11) — More capable models cost more and are typically slower — not fixed permanently, since efficiency improves across model generations.
• Walk through your decision process for choosing which Part 3 components a given application needs. (3.12) — A filter, not a checklist — most real applications correctly exclude several components (RAG, agents, memory) after evaluation.

Frameworks (Parts 4-6)

• Why does create_agent being built on LangGraph matter architecturally? (4.1) — Persistence, checkpointing, and interrupts are available "for free" because the high-level API sits on the same graph runtime.
• What does BaseChatModel normalize across providers, and what does it NOT normalize? (4.2) — Normalizes message/response shape; does NOT normalize actual model behavior — prompts may still need per-provider tuning.
• What are the three underlying strategies .with_structured_output() might use? (4.3) — Native structured output, forced tool-calling, or generate-then-parse — guarantee strength differs by which one is active.
• What does @tool derive automatically, and why does the docstring matter so much? (4.4) — Schema from type hints; the docstring becomes the actual description the model uses for tool selection.
• Why should you verify pre-filter vs. post-filter behavior for a specific vector store integration? (4.5) — The abstraction's convenience can hide which behavior you're actually getting — same risk as 3.4, one layer removed.
• Explain the difference between middleware and callbacks. (4.6) — Middleware actively intervenes at defined hook points; callbacks passively observe every lifecycle event.
• Give an example of a production concern LangChain does NOT automatically solve. (4.7) — Per-user tool authorization, semantic validation beyond schema, tenant isolation — all still your responsibility.
• Explain the partial-update-and-merge model of LangGraph state. (5.1) — Nodes return a delta, not the full state; LangGraph merges it in, using reducers for accumulating fields.
• Why must a custom reducer combining concurrent updates be commutative? (5.2) — Multiple nodes can update the same field within one superstep; order-dependent combination logic produces non-deterministic bugs.
• Explain the durability differences between MemorySaver, SqliteSaver, and PostgresSaver. (5.3) — In-process only; single-machine durable; durable and shared across instances — only the last is production-safe at scale.
• Why does human-in-the-loop pausing depend fundamentally on a persistent checkpointer? (5.4) — interrupt() frees the process by checkpointing state; without durable storage, a paused run is lost on any restart.
• What's the difference between values and updates streaming modes? (5.5) — Full state every superstep vs. only what changed — a bandwidth/processing trade-off.
• Why might a fixed sequential pipeline of subgraphs outperform a dynamic supervisor pattern? (5.6) — A supervisor's routing decision is an extra LLM call on top of every specialist — unnecessary if the task's structure is actually fixed.
• Why does checkpoint-based recovery create an idempotency requirement for side-effecting nodes? (5.7) — A crash-and-resume can re-execute a node whose prior attempt already partially succeeded (e.g., already sent an email).
• Walk through a LangGraph production-readiness checklist. (5.8) — Durable checkpointer, tested branches, idempotent side effects, calibrated HITL, tracing — none automatic from using the framework.
• Explain the trace/run data model in LangSmith. (6.1) — A trace is the full execution tree; a run is one step within it (one LLM call, one tool call).
• Why is building datasets from production traces more valuable than synthetic examples alone? (6.2) — Real traffic reveals actual failure patterns a hand-written dataset likely won't anticipate.
• Why can't offline evaluation alone catch every production quality regression? (6.3) — See top-15 #7.

Production Engineering (Part 7)

• Explain Docker's layer caching and why instruction order affects build speed. (7.1) — Unchanged layers are reused; put rarely-changing steps (dependency install) before frequently-changing ones (code copy).
• What's the AI-specific addition to a standard CI/CD pipeline? (7.2) — An automated evaluation gate (Part 6.2) checking behavior quality, not just code correctness.
• Give an example of a security responsibility that remains yours even with a fully managed cloud service. (7.3) — Your own access-control configuration on a managed database — the provider secures the infrastructure, not your policy.
• Why does pod ephemerality make durable checkpointing non-negotiable on Kubernetes? (7.4) — See top-15 #10.
• Why might scaling out your own instances fail to improve AI-backend throughput? (7.5) — The real bottleneck is often the LLM provider's shared rate limit, which more of your own instances don't relieve.
• Distinguish within-request async concurrency from deferred background processing. (7.6) — One process handling many concurrent requests vs. decoupling a response entirely from when the work finishes.
• Why does at-least-once delivery require idempotent job processing? (7.7) — A job can be redelivered after a worker crash mid-processing; re-running it must be safe.
• Explain the difference between semantic caching and provider-level prompt caching. (7.8) — Semantic: matches paraphrased queries via embedding similarity. Provider-level: caches a shared prompt prefix's processed representation.
• What problem does a centralized LLM gateway solve beyond per-application model routing? (7.9) — Cross-service rate-limit coordination, unified cost visibility, and shared circuit-breaking/fallback.
• Explain the three-factor cost equation and why stacked optimizations compound multiplicatively. (7.10) — See top-15 #9.

Reliability and Security (Parts 8-9)

• Why is outcome-only evaluation insufficient for agent systems? (8.1) — See top-15 #11.
• Explain the precise distinction between faithfulness and factual correctness. (8.2) — Faithful = grounded in the given context; correct = true in reality — a faithful answer can still be wrong if the source was wrong.
• Why must an LLM judge be calibrated against human judgment before trusting it at scale? (8.3) — Documented biases (verbosity, position, self-preference) can silently reward the wrong thing if never checked against human scores.
• Why are traditional uptime/latency SLOs insufficient for AI systems? (8.4) — A system can be fully "green" on infrastructure health while quality or cost silently degrades — needs dedicated quality/cost SLIs.
• Why does normal-usage evaluation not substitute for adversarial red-teaming? (8.5) — Evaluation datasets built from real traffic reflect non-adversarial behavior; red-teaming actively probes for what an attacker would try.
• Why is prompt injection a structural property of LLMs, not a fixable bug? (9.1) — See top-15 #1.
• Explain the excessive-agency risk formula. (9.2) — See top-15 #5.
• How can data exfiltration occur through an AI system without infrastructure compromise? (9.3) — Manipulating the AI's own legitimate access (via injection or a plausible request) rather than breaching the underlying system directly.
• Why is OAuth's scoped delegation preferable to storing raw third-party credentials for agents? (9.4) — A narrow, revocable scope bounds the blast radius of any future compromise, unlike a stored password granting full access.
• Why is "instruct the model not to reveal secrets" not a real defense? (9.5) — A secret must never enter the model's context at all — there's nothing to leak if it was never present, regardless of instructions.
• Why must tenant isolation be audited across every layer data flows through? (9.6) — See top-15 #8.

Enterprise and System Design (Parts 10-11)

• Why is webhook-driven integration generally preferable to periodic polling for RAG freshness? (10.1) — Near-instant staleness window and lower cost (only changed records processed) vs. a real, recurring staleness gap.
• Why is data engineering effort in a real engagement often underestimated? (10.2) — Real enterprise data is rarely clean/deduplicated/consistently permissioned — this work frequently exceeds the AI pipeline's own build time.
• Why should CRM/ERP tools be built around business actions, not raw record CRUD? (10.3) — Raw field updates can bypass the platform's own validation/workflow automation, causing real downstream process failures.
• Why is tenant-level isolation insufficient for a RAG system built on a DMS with internal permission segmentation? (10.4) — Tenant isolation stops cross-organization leaks; it doesn't stop an authorized-tenant user from seeing another employee's restricted document.
• Compare the three multi-tenant isolation patterns and when each is justified. (10.5) — Shared DB (cheap, weakest isolation) / schema-per-tenant (moderate) / database-per-tenant (strongest, often contractually required, most expensive).
• Walk through your system design process and explain why failure modes/security/cost are explicit steps, not an afterthought. (11.1) — A design that hasn't been stress-tested against these three lenses hasn't actually been designed yet, only sketched.
• For each of the 8 system designs (11.2-11.9): what was the single highest-stakes component, and why? — RAG: permission filtering. Support agent: return-processing limits. Multi-tenant SaaS: full-layer isolation. Document intel: confidence-routing. Workflow platform: checkpoint availability. Agent platform: sandbox isolation. Knowledge assistant: federated permission containment. API platform: billing-metering accuracy.

FDE Skills (Parts 12-15)

• Why is "we want a chatbot" a proposed solution, not a requirement? (12.1) — See top-15 #6.
• Why does detailed process mapping reveal automation feasibility that a summary description misses? (12.2) — See top-15 #14.
• Why should the same architecture be communicated differently to different stakeholder roles? (12.3) — See top-15 #15.
• Why is the FDE engagement lifecycle better understood as a loop than a line? (13.1) — Measured impact feeds back into the next discovery conversation, for expansion or the next customer.
• How do you identify the "riskiest assumption" a prototype should target? (13.2) — The single assumption whose failure would most undermine the whole project — not the parts with low uncertainty (a UI, standard deployment).
• What's the deployment-environment spectrum, and what changes architecturally at each step? (14.1) — Cloud-hosted → customer cloud → on-prem connected → air-gapped; the air-gapped case forces a self-hosted model, since hosted APIs require outbound internet.
• Why does measuring against the discovery-established metric matter more than a retroactively-chosen one? (15.1) — Substituting a new, more flattering metric after the fact undermines credibility the moment a stakeholder notices the goalposts moved.

7. Glossary — the terms this handbook uses constantly

• RAG (Retrieval-Augmented Generation): Retrieving relevant content and including it in a prompt so generation is grounded in it, rather than the model's parametric memory alone (3.5).
• Agent vs. Workflow: Who controls step sequence — the model (agent) or fixed code (workflow) (3.7).
• Faithfulness: Whether an answer is actually supported by its given context, independent of whether that context is true (8.2).
• Excessive agency: Risk from an agent having more tool capability/autonomy than a task genuinely requires (9.2).
• Prompt injection (direct/indirect): Adversarial content that manipulates model behavior, arriving from the user directly or hidden in retrieved/tool-result content (9.1).
• Constrained decoding: Masking invalid-per-schema tokens to zero probability before sampling, so schema violation is structurally impossible (3.2).
• Checkpointing: Persisting a graph's state after every step so execution can resume after an interruption (5.3).
• Superstep: One round of a LangGraph execution where all currently-active nodes run, potentially in parallel (5.1).
• Reducer: A function defining how a state field's updates combine (overwrite, append, custom merge) (5.1).
• Tenant isolation: Guaranteeing one customer/organization's data never leaks to another in a shared system (9.6).
• Document-level permission preservation: Enforcing a source system's own per-document access rules, a finer grain than tenant isolation (10.4).
• LLM-as-judge: Using a separate LLM call to score another LLM's output; requires calibration against human judgment due to documented biases (8.3).
• Trajectory evaluation: Assessing an agent's process (tool calls, reasoning steps), not just its final answer's correctness (8.1).
• Circuit breaker: A pattern that stops calling a failing provider temporarily, failing fast instead of piling up doomed requests (7.9).
• Idempotency: A retried or redelivered operation producing the same effect as running it once (1.2, 5.7, 7.7).
• Human-in-the-loop (calibrated): Pausing for human approval specifically at genuinely high-stakes decision points, not blanket-applied everywhere (5.4).
• Provider-level prompt caching: A provider reusing its processed representation of a repeated, marked prompt prefix, at reduced cost/latency (7.8).
• Multi-tenant isolation tiers: Shared database, schema-per-tenant, database-per-tenant — increasing isolation and cost (10.5).
• Discovery (FDE sense): Working backward from a customer's stated want to their underlying need before proposing any architecture (12.1).
• Feasibility probe: A cheap, quick test of the riskiest technical assumption before committing to a full build (12.2, 13.2).

8. The one question that matters most

If an interviewer asks only one thing, it's some version of: "A customer says 'we want an AI chatbot for our employees' — walk me through what you'd actually do." This handbook's complete, worked answer to that exact question is Part 16.8 — read it again now if it's been a while. It traces one engagement through discovery (12), architecture (11), prototyping (13.2), full engineering (1-9), deployment (14), and measured impact (15), citing the specific technique used at each step rather than describing the process abstractly. If you can narrate a version of that trace, specifically and concretely, for a scenario an interviewer gives you live, you have demonstrated this handbook's actual goal.

9. Common mistakes when using this study guide

• Reading the one-line hints as if they were the full answer — they're a self-check trigger, not a substitute for the chapter's actual depth.
• Treating every question as equally likely to come up — use section 3's top-15 list to prioritize a time-constrained review.
• Rehearsing answers to sound polished rather than practicing the underlying reasoning — an interviewer probing a follow-up will expose a memorized-but-not-understood answer quickly.
• Skipping the glossary and re-deriving a definition mid-answer under interview pressure instead of having it fluent in advance.

---

Closing note

This concludes the AI Forward Deployed Engineer Handbook. The front matter's 01-how-to-use.md opened with a promise: that finishing this book would mean you could sit with a customer, understand their real problem, design the appropriate AI solution, build a prototype, turn it into a production system, deploy it, secure it, monitor it, debug it, and measure its business impact. Every part, chapter, and project has been built toward exactly that one continuous capability — demonstrated end-to-end in Part 16.8, distilled into this final study guide, and now yours to practice.

What remains is practice: build the projects in Part 16, run the exercises in every chapter, rehearse the interview formats in this Part against the top-15 list above, and — most importantly — go find a real, messy, ambiguous problem and apply this entire process to it yourself.