Free · structured · practical
Search 中文 Start at lesson 1
Courses/They Will Quiz You/Practice · From Demo to Product · 30 Tough Questions
Part 3 · From Working Demo to Useful Product

Practice · From Demo to Product · 30 Tough Questions

Each with intent, framework, and bonus points: demo-to-launch gap / Agent deadlock / context compression / memory design / multi-Agent / MCP / cost accounting

THE QUESTION THIS PAGE ANSWERS

ANSWER FIRST

What is the key idea behind “Practice · From Demo to Product · 30 Tough Questions”?

Each with intent, framework, and bonus points: demo-to-launch gap / Agent deadlock / context compression / memory design / multi-Agent / MCP / cost accounting

DECISION RULE

Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.

TRY NEXT

Write one question you could answer with evidence after trying this idea.

WATCH FOR

A conclusion that sounds complete but leaves the key assumption untested.

How to Use This Page
Each question is labeled with who is asking. They cover the same knowledge, but what they want to hear is different.
🎙 InterviewerWants to verify whether you've actually shipped it or just watched demos
👔 BossWants an explanation, a plan, and a deliverable promise
🛠 Tech ColleagueTesting how big you draw the pie and how much you understand the costs
Each question has three layers: what they're assessing → answer framework → bonus points. For any part you can't answer, click the course pages at the end to review.
Q1Interviewer
"Say your team got the image-generation API working in a single day and the demo looked great. In your view, how far is that from actually launching? What's missing?"
🎯 What they're assessing
This is the watershed question for judging whether you've actually shipped an AI feature. Someone who has only played with demos will say "just a bit more polish and it's ready"; someone who has shipped knows that getting the API working is only 10%, and the remaining 90% is productization work they can enumerate line by line.
🧭 Answer framework
  1. Start with the conclusion: Getting the API working is only 10%. In real cases, going from working API to launch took three months. The gaps can be categorized across four dimensions.
  2. Experience layer: Generation progress feedback, one-click retry on failure, multiple results to choose from, history to revisit. In a demo, the user can sit and wait 30 seconds with no feedback; in a product, that's unacceptable.
  3. Quality and engineering layers: Quality relies on Prompt optimization (using an LLM to translate user plain language into descriptions the image model understands) plus character consistency anchoring; engineering relies on multi-model fallback chains, timeout retries, cost caps, and result persistence. The model will definitely fail — the experience after it fails is what makes a product.
  4. Safety layer: Dual content moderation (input and output), copyright risk, and privacy policy for user reference images. A demo can go bare; a production product that goes bare will have incidents.
⭐ Bonus point Mention the universality of this checklist: for any AI feature, the path from Demo to Production always covers experience, quality, engineering, and safety. Hearing that you have a methodology impresses the interviewer far more than just hearing you recite a list.
Organize your answer using these lesson pages → Image generation productization checklist Using AI to write Prompts for AI The model will fail — what then?
Q2Boss
"A user reported that the Agent ran for half an hour and never stopped — and gave nothing back in the end. What happened? How do you plan to make sure this never happens again?"
🎯 What they're assessing
The boss wants both a root cause explanation and a prevention commitment. Saying "the model went haywire" reveals you: it means you can neither articulate the failure patterns nor produce a mechanism to make it stop on its own. Answering "I'll have engineering add a timeout" only gets half credit — that's just the crudest layer.
🧭 Answer framework
  1. Explain the root cause first: Production Agent deadlocks fall into four typical patterns: same-parameter loops (repeatedly calling the same tool with the same parameters), diminishing returns (50 rounds of nothing but marginal actions), text repetition (rehashing the same content once context gets too long), and cascading tool failures (one tool fails and drags down the whole chain). Start by identifying which pattern this was.
  2. Provide the protection plan: Mistake-proofing is a three-layer net. Hard limits as the safety floor: iteration cap, total timeout, per-tool call count limit — unconditional brakes. Detection and alerts: same-parameter detection, same tool name detection, diminishing returns detection — report any anomalous pattern.
  3. Graceful degradation: When anomalies are detected, first gently correct: inject a note like "you've repeated this 3 times, please try a different approach," temporarily disable the failed tool, force a summary of current progress and return with a partial result. For users, coming back with something partial is far better than empty hands.
  4. Add the experience layer commitment: Even when the Agent is running a long task, users need to see progress — show what it's currently doing and allow manual stops at any time. What users are actually angry about is "I waited half an hour and had no idea what it was doing."
⭐ Bonus point Add: "Users never report that the Agent is in a loop — they just say 'this AI is so slow and stupid' ". Being able to translate a technical failure into the user's perspective makes the boss feel you're the person who can handle this.
Organize your answer using these lesson pages → Why Agents get stuck in loops Mistake-proofing: how to make loops stop on their own Streaming UX: don't leave users waiting
Q3Interviewer
"Your AI assistant gets more expensive and dumber the longer the conversation. How would you design context compression? What can be deleted, and what is absolutely off-limits?"
🎯 What they're assessing
This tests whether you have a compression decision framework and whether you know where the red line is. Answering "just find a model to summarize it" reveals you: you've neither calculated the cost of summarization itself nor realized that deleting the wrong things leads to users discovering "I clearly said that — how did you forget it?"
🧭 Answer framework
  1. Explain why compression is necessary: Every turn of the conversation re-sends the entire history to the model. The longer the conversation, the higher the cost, the more scattered the attention, the closer to the context window limit — three problems that force you to manage context.
  2. Provide a tiered framework: Deletable: old tool call results, already-processed intermediate steps. Compressible: AI's lengthy replies, search results — compress to a one-sentence summary. Absolutely untouchable: the user's original messages, System Prompt, key preference settings.
  3. Identify the red line: The user's words are sacred. Better to delete 1000 words AI said than to touch 10 words the user said. Compression priority, highest to lowest: tool outputs, AI replies — user messages are never touched.
  4. Clarify the cost of each method: Local compression (truncation, rule-based replacement) is free but coarse; LLM summarization is precise but costs tokens. The correct order is free-first, then paid: use local methods to cut obvious bloat first, then consider LLM summarization for what remains.
⭐ Bonus point Proactively raise the user experience angle: good compression is invisible to users; poor compression makes users feel AI has "amnesia". Treating compression as a UX metric and measuring it transcends the pure cost-saving perspective — very few people offer this angle.
Organize your answer using these lesson pages → Longer conversations cost more and get dumber Compression is the art of trade-offs Can the user's words be deleted? Local compression vs. LLM compression
Q4Interviewer
"The product needs to 'make AI remember the user'. How would you design this memory system? Do you store every conversation? What happens when the user changes their mind?"
🎯 What they're assessing
Three chained questions testing your complete design capability for a memory system: what to store, how to update, how to use. Conflating "memory" with "context" reveals you in the first sentence; answering "store everything and query it later" won't pass the cost and noise test.
🧭 Answer framework
  1. Distinguish the two systems first: The context window is a whiteboard — fill it and erase it, clear it when the conversation ends. Long-term memory is a notebook — what is written remains the next time it opens. The prerequisite for building a memory feature is accepting that the whiteboard is unreliable.
  2. Design the gatekeeper: Users send dozens to hundreds of messages a day, with "ok", "sure", "haha" making up the majority. The preferences and facts worth remembering are only a few. There needs to be a filtering logic before writing to memory to judge whether information has long-term value.
  3. Handle memory conflicts: A user said last month they like coffee, this month they switched to tea. Four strategies by scenario: explicit replacement → overwrite; complementary information → merge and extend; cannot determine which is correct → mark as conflict pending confirmation; temporary states (lately too tired, sleeping in) → skip and don't store.
  4. Calculate the injection cost: With 1000 stored memories, stuffing them all into the System Prompt every time is simple but expensive and noisy; on-demand retrieval saves money but may miss things. The injection strategy must be chosen based on memory scale and scenario — this is a cost decision.
⭐ Bonus point Point out: "The core capability of a memory system is updating — a memory system that only appends will become a rumor database in two months." Most people only design the write path, not expiration and error correction.
Organize your answer using these lesson pages → Context ≠ Memory What's worth remembering and what isn't Memory conflicts: what when users change their mind The cost problem of memory injection
Q5Tech Colleague
"Your PRD says you need multi-Agent collaboration and you drew a pretty cool architecture diagram. Do we really need that many Agents? Can't one Agent handle it?"
🎯 What they're assessing
The tech colleague is probing whether you've genuinely thought it through or are just chasing trends. Multi-Agent means more coordination cost and more failure points — they will be paying for this complexity. If you can't answer "why a single Agent won't do it," this requirement will most likely be pushed back.
🧭 Answer framework
  1. Acknowledge the default position first: The default is that one Agent is sufficient. Many so-called multi-Agent scenarios are actually just poorly written Prompts. Before adding a second Agent, answer three questions: can one really not do it? Is the complexity worth it? Is there a simpler solution (like parallel tool calls)?
  2. Name the three genuinely required scenarios: Parallel speedup — searching 5 sources simultaneously is 5× faster than serially. Role separation — Writer writes, Reviewer reviews; role isolation makes the review genuinely effective. Risk isolation — if a sub-Agent fails to parse a PDF it only reports "this file has a problem" and the main task is unaffected.
  3. Map to the scenario: Return to the specific scenario in the PRD and explain which of the three it matches. If it matches, keep it; if it doesn't, cut it on the spot — that looks far better than defending an architecture diagram.
  4. Demonstrate concurrency common sense: Even with multi-Agent, know that "reading" can be parallel and "writing" must be serialized. The one key to judging whether an operation can be concurrent: is it read-only?
⭐ Bonus point Proactively say: "If none of these three scenarios applies, I'll revert to a single Agent." The thing tech colleagues fear most is a PM they have to pay for in slide-deck architecture — naming your own exit builds trust immediately.
Organize your answer using these lesson pages → When do you need multiple Agents The cost of concurrency: who can run in parallel Brainstorm: let multiple AIs argue
Q6Interviewer
"MCP is very hot right now. Tell me how it's different from a regular API call. What does it mean for your product?"
🎯 What they're assessing
This tests how deep your understanding of MCP goes. Answering "a protocol that lets AI call external tools" is indistinguishable from someone who read one explainer article. People who truly understand MCP will explain the bidirectionality: your product can both consume others' capabilities and expose itself as a tool for others.
🧭 Answer framework
  1. First layer: As a Client, the product consumes external capabilities through MCP — calendar, email, database, browser — connect to one protocol and gain access to an entire ecosystem, eliminating the cost of integrating APIs one by one.
  2. The critical second layer: MCP is bidirectional. The product can also act as a Server, exposing its own capabilities for Cursor, Claude Desktop, or automation scripts to call. One-way integration is just tool calling; bidirectional means your AI can become a tool for others.
  3. State the product implication: When multiple Agents can call each other, an ecosystem forms naturally. This is the key leap from tool to platform, and it's a product positioning decision that PM must make.
  4. Add engineering common sense: Connecting to 10 MCP services at startup all at once? If 3 are down, startup hangs. Registration and connection must be separated — lazy connection (connect when used). Going further, when an Agent discovers it lacks a tool at runtime, it can discover and configure a new MCP connection on its own.
⭐ Bonus point Close with one sentence: "MCP's significance for AI products is analogous to what open platforms meant for mobile internet — figure out first whether you're the integrator or the integrated." Elevating a protocol question to an ecosystem positioning question will make you memorable.
Organize your answer using these lesson pages → MCP is more than just "calling tools" Lazy connection: don't connect until needed AI adds its own tools
Q7Boss
"This month's API bill tripled compared to last month, but user growth was only 20%. Where did all the money go? Can we bring it down next month?"
🎯 What they're assessing
This tests whether you understand the cost structure of Agent products. Someone who thinks cost is proportional to message count can't explain why the bill grows faster than user count. Only someone who can break the bill down to the level of turns and context length can talk about how to reduce it.
🧭 Answer framework
  1. Correct the unit of measurement first: A user sends one message, but under the hood it may run 10+ loop iterations and dozens of API messages, and every iteration re-sends the full history. Cost is tied to task complexity and grows exponentially with it, so the bill growing faster than user count is normal — out-of-control growth is the problem.
  2. Hunt the typical cost culprits: Scheduled tasks reusing old sessions where context keeps growing — one choice can make monthly bills differ by 10×. Stuck loops burning money on idle iterations. Long conversations without compression, paying for ancient history every turn.
  3. Provide the cost-reduction combination: Switch scheduled tasks to creating a new session each time. Deploy loop safeguards to kill idle iterations. Context compression to cut tokens that shouldn't be resent. Set cost caps by user and time slot, and monitor anomalous calls.
  4. Provide a way to quantify the commitment: Build a monitoring dashboard for per-task average cost. Transform "can we lower it next month" into "per-task cost target and anomalous calls to zero" — report weekly.
⭐ Bonus point Add: "The flip side of cost increases is that over-saving makes the AI dumber, and too much compression degrades experience." Proactively putting the cost-experience trade-off on the table shows you're making product decisions, not just playing accountant.
Organize your answer using these lesson pages → The real cost behind one message The cost trap of scheduled tasks Longer conversations cost more and get dumber
Q8Interviewer
"We're adding image generation to the product. How would you choose between text-to-image and image-to-image? Don't say 'try both' — give me a few concrete scenarios."
🎯 What they're assessing
They want to know whether you understand that this is the first fork in an image-generation product. Text-to-image and image-to-image are two completely different product strategies. Anyone who answers "whichever looks better" has never made this call in a real product.
🧭 Answer framework
  1. Start with the core difference: Text-to-image creates from nothing — the model imagines the character differently every time. Image-to-image uses a reference image as an anchor: appearance is locked, and only the scene and action change.
  2. Give a scenario contrast: Pure backgrounds, food or object close-ups, creative exploration — use text-to-image: more freedom, cheaper too. Character on camera, outfit changes (same face, different clothes), multi-scene series — must use image-to-image, or users will notice "why does this person look different in every shot?"
  3. Give a decision rule: Ask one question: "Does this image have a 'it must still be the same person' constraint?" If yes, image-to-image. If not, text-to-image is more flexible.
  4. Add the product implication: Choosing image-to-image means you first have to build a set of standard reference-image assets. That's product-side work that has to be in the schedule.
⭐ Bonus point Spell it out: "Whether you have a reference image decides two completely different product strategies." What differs isn't just output quality — it's the entire asset pipeline and cost structure.
Organize your answer using these lesson pages → Text-to-image vs. image-to-image Character consistency
Q9Interviewer
"The user types 'draw a cat under a sunset'. Can't we just send that sentence to the image model? Why put an LLM in the middle and spend extra money?"
🎯 What they're assessing
They want to know whether you understand the core architecture of an image-generation product: the Prompt re-translation layer. It looks redundant; it's actually the bottleneck of output quality. Anyone who can't explain "why you must translate" will ship an image feature that's basically a gacha machine.
🧭 Answer framework
  1. Lead with the conclusion: What the user wants and what the image model needs are two different languages. You need an LLM in the middle to translate — expanding one sentence into a few hundred tokens of precise visual description.
  2. Give three reasons: Users don't write image Prompts; nobody voluntarily types "golden hour lighting." The model can't parse vague intent — "zoning out" has no picture for it. And every image model has its own dialect: Midjourney, DALL-E, and Stable Diffusion all prefer different things, so you customize for the target model.
  3. Give an example: "the example system zoning out on the balcony," after the translation layer, becomes a long English description covering pose, expression, lighting, hairstyle, her signature necklace, and composition — and the output actually stays stable.
  4. Place it in the architecture: This translation layer belongs on the image-generation productization checklist. It's fixed architecture. Skipping it saves a little money and costs you output quality.
⭐ Bonus point Add: the translation layer is also where you uniformly inject character traits (anchors like hairstyle and necklace). It grows naturally together with your character-consistency strategy.
Organize your answer using these lesson pages → Using AI to write Prompts for AI Image generation productization checklist
Q10Tech Colleague
"This bug you filed — 'the IP character looks different every time we generate' — I can just tweak the temperature and pin the seed, right? Not a big deal."
🎯 What they're assessing
Engineering is probing whether you treat character consistency as a parameter-tuning problem or a product-design problem. If you nod along, in two weeks the same bug will be back — plus a new line: "we already tuned the parameters."
🧭 Answer framework
  1. Name it first: This is one of the hardest problems in an image-generation product. Tweaking parameters won't fix it. Generate four times from a pure text description and face shape, hair, body, and art style all drift. Text cannot lock a visual identity.
  2. Give the solution: Build a standardized Character Reference Sheet for the IP. Every generation, send the reference image with the request so the model "draws while looking" — image-to-image as the anchor.
  3. Say what you lock: Face and body (feature proportions, silhouette), expression style (prepare multiple expression variants in advance), wardrobe (signature outfits; in costume-change scenes, change clothes, not the face).
  4. Add the boundary: Some fallback models in the degradation chain don't support image-to-image. Switching to them degrades to pure text-to-image and consistency drops. Declare that loss in the fallback plan up front — don't treat it as an incident later.
⭐ Bonus point Volunteer the product-side workload: making and maintaining reference-image assets is something the PM has to drive. Don't let engineering think you only file requests.
Organize your answer using these lesson pages → Character consistency Text-to-image vs. image-to-image The model will fail — what then?
Q11Interviewer
"Your image generation depends on third-party models. One day Gemini times out and Seedream rate-limits you — what does your product do? Walk me through your fallback design."
🎯 What they're assessing
They want to know whether you have the engineering instinct that "the model will definitely go down". Anyone who answers "wait for it to recover" or "show an error" has never been woken up by a 3 a.m. alert.
🧭 Answer framework
  1. Walk the chain first: Model A times out at 15 seconds and trips the circuit breaker, automatically switch to model B; B is rate-limited, keep going to C; C produces the image. The user only sees "drawing…" and never notices three models swapped underneath.
  2. Give three mechanisms: Priority plus a whitelist — character shots use the most consistent model, pure backgrounds use the cheap-and-fast one. Health checks — periodically probe each model's status, skip confirmed outages, come back automatically when they recover. Image-to-image fallback — if the backup model doesn't support it, degrade to text-to-image: quality drops a notch, but you still get an image.
  3. Give the all-down fallback: When every model is down, a friendly message: "We're busy — you've been added to the queue, we'll notify you when it's done." Never a cold error page.
  4. Close with a principle: Users don't care which model died. They care whether the image comes out. The goal of fallback design is to translate a failure into the smallest possible wait.
⭐ Bonus point Say the acceptance criterion for the fallback chain is the "worst-case experience": if it's designed well, the worst case is a few extra seconds or a friendly message. That's what productization looks like.
Organize your answer using these lesson pages → The model will fail — what then? Image generation productization checklist
Q12Interviewer
"Your resume says you're familiar with Agents. So walk me through the Agent loop — it's just the three-step circle of 'think, act, observe,' right?"
🎯 What they're assessing
This is a trap. They want to know whether you memorized the textbook or have seen production. Anyone who nods and says "right" falls in. The interviewer is waiting for you to name the parts the textbook left out.
🧭 Answer framework
  1. Catch it first: Textbook ReAct really is Think, Act, Observe. That's the skeleton — correct, but nowhere near complete.
  2. Then expand: In production, one loop actually runs about 11 steps. The extras include context trimming and token-budget checks, system-instruction injection, permission checks and parameter validation, concurrent scheduling, timeout monitoring and error fallback, writing results back, and security audit logs.
  3. Name the essence: Those extra steps are the bulk of the engineering. Whether an Agent is stable, safe, and usable depends exactly on the parts that aren't in the textbook.
  4. Pick one and go deep: The permission-check step decides whether the current user can call this tool and whether the parameters are legal. Skip it, and day one of launch is a security incident.
⭐ Bonus point Add a scheduling angle: a real Agent does about 5× more work per loop than the textbook. Estimate workload on 11 steps. A schedule built on 3 steps will blow up.
Organize your answer using these lesson pages → Textbook's 3 steps vs. real-world N steps Mistake-proofing
Q13Interviewer
"A tool call is going to run 30 seconds in the background. What should be on the user's screen during those 30 seconds? Walk me through your plan."
🎯 What they're assessing
They're testing your AI product interaction craft. Anyone who only says "add a loading spinner" hasn't thought about waiting. The interviewer wants a complete progress-feel design.
🧭 Answer framework
  1. Lead with the principle: Users can tolerate waiting. They cannot tolerate not knowing what they're waiting for. Three rules of progress feel: let users see the process, make progress perceptible, and let output appear gradually.
  2. Give a toolkit: Status copy ("Searching…", "Analyzing…"); show the name of the tool currently being called; stream tokens as they arrive; stage markers (step 1 / 3); surface intermediate artifacts first — outline first, details later.
  3. Give a contrast: Same 30-second wait. One side is a spinning animation and the user suspects a freeze. The other is a rolling status stream — "found 3 results," "analyzed 2/5 files" — and the user is reading. They feel like two different products.
  4. Add a layer of control: Long tasks need a stop button that's always one tap away. Waiting you can cancel is waiting that doesn't make people anxious.
⭐ Bonus point Spell it out: "progress feel ≠ a progress bar." AI task duration was never precisely estimable. The core is making users feel the AI is actually working. Streaming output is itself the best progress bar.
Organize your answer using these lesson pages → Streaming UX: don't leave users waiting Mistake-proofing
Q14Tech Colleague
"Your PRD says 'keep per-task cost under 5 cents.' Do you know how many tokens actually burn when a user says 'help me refactor this module'?"
🎯 What they're assessing
Engineering is probing whether the cost number in your PRD was calculated or guessed. A PM who can't name the order of magnitude writes cost targets nobody takes seriously.
🧭 Answer framework
  1. Name the order of magnitude: A simple task like checking the weather — 2 loop turns, 6 messages, about 1000 tokens, $0.003. Analyzing a PDF takes 6 turns, about 5700 tokens, $0.02. Refactoring code takes 12 turns, twenty-plus messages, nearly 8000 tokens, $0.08. Task complexity differs, cost differs by tens of times.
  2. Point at the cost bulk: The System Prompt is resent every turn. Long tool returns (entire file contents, full-page search results) are a hidden heavyweight. Context snowballs — every later turn carries every earlier message.
  3. Fix how the metric is written: Set cost caps by task type, plus per-task cost monitoring. Don't slash one number across everything.
⭐ Bonus point Name the most counterintuitive thing about Agent cost: it snowballs with turns, growing faster than linear — completely different from the traditional "one call, one charge" API intuition.
Organize your answer using these lesson pages → The real cost behind one message Longer conversations cost more and get dumber
Q15Interviewer
"Users say your AI gets dumber the longer they chat, and keeps forgetting requirements they already stated. Is that a user illusion, or is there a real mechanism behind it?"
🎯 What they're assessing
They want to know whether you understand the triple cost of long context. Anyone who answers "maybe the model is unstable" doesn't understand the context mechanism. This one is not the model's fault.
🧭 Answer framework
  1. Lead with the conclusion: Not an illusion — three mechanisms stacked. Cost inflation: every turn resends the full history; turn 8 can cost 20× turn 1. Attention decay: the model is hot at both ends of the context and cold in the middle; an important ask from turn 3 is likely ignored by turn 8. Window overflow: once the 128K window fills, the earliest messages are simply dropped — the AI genuinely cannot see them.
  2. Separate the symptoms: "Getting dumber" mainly comes from attention decay and window overflow. "Getting more expensive" comes from cost inflation. Two symptoms, one root: context growing without restraint.
  3. Give the action: Context management is mandatory. Ship a compression strategy, and separately protect key information like user preferences so it doesn't get diluted with the long conversation.
⭐ Bonus point Name the most counterintuitive one: users think the AI forgot what they said first. Attention is actually lowest in the middle of the conversation — the request from that middle turn is the most dangerous.
Organize your answer using these lesson pages → Longer conversations cost more and get dumber Compression is the art of trade-offs
Q16Tech Colleague
"For context compression I'm just going to call a model to summarize — the quality's good anyway. Run it every turn. Fine with you?"
🎯 What they're assessing
He's holding a hammer and everything looks like a nail. They want to know whether you understand that compression is a pipeline — free first, paid later. Reverse the order and you're paying money to be lazy.
🧭 Answer framework
  1. Put both methods on the books: Local compression uses regex, truncation, template replacement — zero cost, under 1 ms latency, but coarse. LLM compression has another model read and write a summary — precise, keeps the meaning, but every run is an API bill and 1 to 5 seconds of latency.
  2. Give the right order: A four-step pipeline. Local truncation first — drop tool outputs, chop oversized JSON. Then template replacement — swap repeated structures for placeholders. Then check whether you're still over the window. Only if you still can't fit do you ask an LLM to refine, as the last step.
  3. Split by content: Tool outputs, JSON results, repeated content — local compression is enough. Multi-turn conversation summaries and dense context are what deserve LLM money.
  4. Close it: Running an LLM summary every turn is a fixed tax on every conversation. The two methods are sequential stages on one pipeline, not an either-or.
⭐ Bonus point Remind him of compression priority: delete raw tool output first, then compress the AI's own replies, never touch the user's original words. No matter how cheap the method, deleting what the user said is negative points.
Organize your answer using these lesson pages → Local compression vs. LLM compression Can the user's words be deleted?
Q17Interviewer
"Your memory system stores 1000 user memories. Each conversation — do you stuff all 1000 into the model, or what?"
🎯 What they're assessing
They want to know whether you've run the cost numbers on memory injection. Anyone who answers "stuff them all in, it's safer" hasn't done the math, and doesn't know noise will drown the model.
🧭 Answer framework
  1. Kill full injection first: It only works when memories are few. Stuff 1000 items into the system prompt and you pay for that pile of tokens on every call. Most of them are irrelevant to the current question — pure noise — and the AI can't find the point.
  2. Give the recommended path: After the user sends a message, run semantic retrieval first. Pull the 3 to 10 most relevant items from the memory store, inject only those into the system prompt, then let the model reply.
  3. Name the core principle: Memory's value is being able to pull the most relevant few items each time. How many you stored doesn't matter. As memory grows, on-demand retrieval is the only scalable approach.
  4. Close with an analogy: A good memory system is like a competent secretary. It never wheels the entire filing cabinet into the meeting room — it puts today's three files on the table in advance.
⭐ Bonus point Add the trade-off: on-demand retrieval can miss a recall, so leave retrieval parameters for the product to tune. Better to retrieve two extras than let the user discover "I clearly said that last time."
Organize your answer using these lesson pages → The cost problem of memory injection What's worth remembering and what isn't
Q18Interviewer
"How long is your System Prompt right now? Who maintains it? If you change one sentence, do you need a full regression test?"
🎯 What they're assessing
Three questions in a row all point at one thing: is your System Prompt a blob of text or an engineered system. Anyone who can't describe the structure will, the moment the product gets a bit complex, sink into "change one place, break three."
🧭 Answer framework
  1. Give the structure first: A production System Prompt is managed in four layers. Identity — who I am: name, personality, capability boundaries, almost never changes. Environment — what's going on now: user language, system state, may differ every session. Tools — what I can use, added and removed as features iterate. Behavior — how I act: output format, decision priority, safety guardrails, iterated most often.
  2. Explain the payoff of layering: Change one layer without touching the others — add a tool, only the tool layer moves; tweak style, only the behavior layer. Product, engineering, and ops each edit their own files; Git merges don't collide.
  3. Answer the regression question: A/B tests replace only the behavior layer; the other three stay put — one variable. When something breaks, debug by layer: wrong persona, stale environment, bad tool description, or conflicting rules — look one layer at a time.
⭐ Bonus point Point out that frequency difference is the layering criterion: the identity layer doesn't move for years; the behavior layer changes every week. Mixing things with different change frequencies in one file is repeatedly exposing the stable stuff to fat-finger risk.
Organize your answer using these lesson pages → System Prompt is not a blob of text
Q19Tech Colleague
"We keep adding tools — almost 100. All the tool descriptions live in the System Prompt, and one request burns tens of thousands of tokens on descriptions alone. What do we do?"
🎯 What they're assessing
They want to know whether you know the fix called on-demand loading, and that it saves far more than money. Once tools pile up, stuffing them all in isn't just a token bill — it's also the chance the model picks the wrong tool.
🧭 Answer framework
  1. Confirm the bill first: The course estimate: loading all 100 tools is about 34,000 tokens; on-demand loading needs about 2,800 — over 90% saved. That money is spent on every single request.
  2. Give a three-step plan: First turn, names only — tool name plus one-sentence description, so the AI knows the capability exists. When the AI decides to call it, the system dynamically injects the full description and parameter schema. After use, pull it back — next turn returns to names only.
  3. Name the second payoff: AI is like people — too much information and it can't find the point. On-demand loading saves money and also raises tool-selection accuracy.
  4. Give the team an analogy: A company directory doesn't include everyone's full resume. Names and titles only; look at the details when you actually need to collaborate.
⭐ Bonus point Tie this to caching: if tool descriptions sit in the System Prompt prefix and get added and removed constantly, you also blow the KV Cache. On-demand loading is three birds with one stone.
Organize your answer using these lesson pages → Don't show AI what it doesn't need The subtle relationship between Prompts and caching
Q20Interviewer
"System Prompt, Tool, Skill — what does each one own? Why not just write the Skill content straight into the System Prompt?"
🎯 What they're assessing
They want to know whether you can explain the Prompt system in terms of responsibility boundaries. Products that mix these three can't iterate behavior and can't trace it. The interviewer is watching whether you treat Prompts as assets to be managed.
🧭 Answer framework
  1. One-sentence split: System Prompt owns who I am — global identity, rarely changes. Tool owns what I can do — the capability menu, medium-frequency changes. Skill owns how to do a specific thing well, step by step — task-specific process guidance, high-frequency iteration, independent versions.
  2. Unpack a Skill's structure: Trigger conditions decide when to load. An allowed-tool whitelist controls risk. The execution flow writes every step from confirming the ask to delivery. Output-format requirements keep quality consistent every time.
  3. Answer why it doesn't go into the System Prompt: The System Prompt is global — change it and every scenario is affected. Skills load on demand, injected only when the task matches, and don't pollute other tasks. And files are config: who changed what is obvious in Git.
  4. Land the ops value: Skills make Prompts reusable, iterable, and traceable. Changing a file changes behavior. That's the starting point of managing Prompts like code.
⭐ Bonus point Add a lifecycle view: write, register, trigger, iterate — four steps, one file per task. Being able to draw that loop in an interview beats reciting three nouns by a lot.
Organize your answer using these lesson pages → Skill: an operable Prompt module System Prompt is not a blob of text
Q21Tech Colleague
"I just concatenated the Skill content into the System Prompt — simplest to implement. The bill's been creeping up lately. Related?"
🎯 What they're assessing
They want to know whether you understand KV Cache prefix-hit rules, and whether you can hook an implementation detail to a rising bill. This is one of the rare moments a PM can point directly at an engineering cost save.
🧭 Answer framework
  1. State the rule first: The cache fingerprints the System Prompt. The prefix has to be identical to hit; one character off and everything recomputes. This isn't just a timestamp problem — any dynamic content inserted into the prefix does the same thing.
  2. Name the problem: Concatenating Skills into the System Prompt means switching Skills is switching prefixes, and the cache dies immediately. In the course simulation, this injection style hits around 20%.
  3. Give the fix: Append the Skill as a separate message after the System Prompt. The prefix never changes; hit rate can reach around 90%. Same for user IDs, session tags, anything that changes — put it all after.
  4. Give the principle: Don't touch the prefix. Put everything that might change after the System Prompt, and keep the prefix forever stable.
⭐ Bonus point Connect this to the classic counterexample from the Harness core lesson: a dynamic timestamp killing the cache is just one special case. This lesson's conclusion is broader — any dynamically injected prefix content is a cache killer.
Organize your answer using these lesson pages → The subtle relationship between Prompts and caching Skill: an operable Prompt module
Q22Interviewer
"In a multi-Agent system, which operations can run at the same time, and which have to queue? Give me one rule I can actually ship."
🎯 What they're assessing
They want to know whether you can compress the engineering idea of concurrency into one product-executable rule. Naming the rule and the exception is what counts as actually understanding it.
🧭 Answer framework
  1. Give that rule: After this operation runs, did the world change? If not, it can run in parallel; if yes, it has to queue. Search, read a file, hit an API — read-only; ten of them at once don't affect each other. Write a file, send email, take a payment — they change external state. Two writers on one file is a data overwrite.
  2. Do the math: The course example: 3 searches plus 1 write. Parallel orchestration about 4 seconds; fully serial about 8. Run searches in parallel, write last — time cut in half.
  3. Add the exception: Two writes that change different things — different files, different tables — can also run in parallel. Conflict only happens when multiple operations change the same resource.
  4. Land it as a design action: Step one of designing a multi-Agent system is splitting tools into read and write. That classification is an input product owes engineering.
⭐ Bonus point Turn the rule into a one-line memory hook: look together, change in line. That's usually the sentence the interviewer remembers.
Organize your answer using these lesson pages → The cost of concurrency: who can run in parallel When do you need multiple Agents
Q23Interviewer
"Having three AIs discuss the same question — is that different from asking the question three times? If you built a brainstorm feature, how do you make sure it isn't just fooling itself?"
🎯 What they're assessing
They want to know whether you understand the key mechanism of brainstorm mode. Get it wrong and three Agents just agree with each other — output no different from asking once, at 3× the cost.
🧭 Answer framework
  1. Give the mechanism first: Throw the same question to multiple Agents. Each answers independently from a different role — product view, data view, user view — and a host Agent integrates at the end.
  2. Name the iron rule: Each Agent must think independently and cannot see the others' answers. Same reason as human brainstorming: write alone first, discuss together later. If B sees A's answer, B gets pulled off course and the brainstorm is dead. That's the real difference from asking three times: asking three times is three samples in the same context — the viewpoint never changed.
  3. Talk about the output: The host doesn't only collect consensus — it also flags disagreement. Three Agents agreeing means the direction is clear. Disagreement means the question deserves a deeper discussion. The disagreement itself is the value.
  4. Add the efficiency math: Thinking tasks are naturally parallel. Three Agents thinking at once, total time equals the slowest one — time doesn't triple, money does. So only use it on questions that deserve multiple viewpoints.
⭐ Bonus point Point out that role design is product work: what persona you write for each of the three Agents decides the quality of the viewpoint gap. That matters far more than "just run a few more."
Organize your answer using these lesson pages → Brainstorm: let multiple AIs argue When do you need multiple Agents
Q24Boss
"We have the AI summarize sentiment every hour — nice feature — but I watch this line's cost climb every day, and the month-end bill scared me. What's going on?"
🎯 What they're assessing
"Climbing every day" is the key clue. It points at the cost snowball of scheduled tasks reusing a session. You need to reverse-engineer the implementation from the shape of the bill, and give a fix that works immediately.
🧭 Answer framework
  1. Name the root cause: The scheduled task reused the old session, so context accumulates every run. Run 1 is about 2000 tokens, run 10 about 20,000, run 24 about 48,000. Every request pays for the entire history, so the bill climbs day by day.
  2. Give the fix: Create a new session every run, start from zero. Run 24 costs exactly the same as run 1. The course comparison: 7 days, 24 runs a day — reused session about $50, new session about $5, a 10× gap.
  3. Answer why you can change it: Most scheduled tasks don't need memory. Summarizing today's sentiment is enough; they don't need to know what was summarized yesterday. If something truly needs to carry over, store a summary externally and bring it in next time — don't drag the full history.
⭐ Bonus point Give the boss an inspection habit: whenever an AI feature's cost curve bends up over time, first check whether context is accumulating. Once you've seen the pattern, you recognize it at a glance.
Organize your answer using these lesson pages → The cost trap of scheduled tasks Longer conversations cost more and get dumber
Q25Interviewer
"How are permissions set for the AI in your product? One standard for every feature, or different ones? What's the basis?"
🎯 What they're assessing
They want to know whether you design permissions as a spectrum, not a switch. Anyone who answers "we require confirmation for everything" or "we trust the AI" hasn't even started.
🧭 Answer framework
  1. Plant the spectrum view first: From fully autonomous to approve-every-step is a spectrum, with several notches in between. Full autonomy and the AI can wreck everything; approve every step and users go insane. The product's job is to find each class of operation its place on the spectrum.
  2. Give three positioning dimensions: Reversibility of the action — sending a message is irreversible, reading a file is reversible. Cost of being wrong — deleting data is expensive, search is cheap. User trust — new users cautious, long-time users get more leash.
  3. Answer whether you split them: In the same product, different features use different permission modes. Auto-run for reading the calendar, confirm for sending email — that's the normal shape. One rule for everything is laziness.
  4. Land the essence: How much freedom you give the AI is, at heart, answering a product question: if this goes wrong, who is responsible?
⭐ Bonus point Add dynamism: the permission position can evolve with trust. A user who's been around three months and confirmed a hundred times with no incidents can get an option: "don't ask me about this kind of thing again."
Organize your answer using these lesson pages → How much freedom should AI have Too many popups frustrate users; no popups means no safety
Q26Interviewer
"Users complained there were too many confirmation popups. We cut them, then someone deleted the wrong thing. How do you judge the line on popups?"
🎯 What they're assessing
They want to know whether you can use risk grading to get out of the "popup or no popup" binary. This is the most common experience-vs-safety conflict in Agent products. Almost every interview asks it in a different costume.
🧭 Answer framework
  1. Break the question: The problem is no grading. Popup on every step and after five Allows the user wants to uninstall. Popup on nothing and a wrong delete has no safety net. The answer is auto-run for low risk, must-confirm for high risk.
  2. Give the grading line: Read a file, search, check the calendar — operations that don't change state, no popup. Delete a file, send a message, pay, change permissions — irreversible or high-impact, must confirm.
  3. Answer who sets the grade: Three options. The PM predefines each tool's risk level at design time — most common. Let the AI decide from context whether to ask a human — more flexible, not always accurate. User-custom — most flexible, has configuration cost. You can combine them; the floor is always set by a human.
  4. Raise it one level: Good permission design isn't a binary of popup or not. It's fine-grained control of when to popup and what the popup says.
⭐ Bonus point Mention that popup copy is part of the grading: a high-risk popup has to say this action is irreversible and what it affects, so the user is making an informed decision — dismissing an annoying box doesn't count.
Organize your answer using these lesson pages → Too many popups frustrate users; no popups means no safety How much freedom should AI have
Q27Boss
"A user said the Agent ran in the background for three minutes before anything came back. Can you tell me clearly what it was doing in those three minutes?"
🎯 What they're assessing
The boss is asking once. What they actually want is the ability to answer this kind of question at any time. If you can't, the product is a black box — and a black box can't optimize cost, debug failures, or improve experience.
🧭 Answer framework
  1. Name it honestly: If I can't be precise today, we're missing observability. Answering how many tools it called, how many loop turns it ran, how many tokens it spent, and whether anything failed in the middle depends on an event stream and an execution report — not guessing.
  2. Say what to build: Put a dashboard on the Agent. Execution timeline, tool-call stats, token-spend distribution, an execution report per task.
  3. Talk value for both sides: For engineering: locate which step broke, find idle loops and wasted tokens. For product: understand real usage paths, quantify each feature's cost, feed data into the next iteration.
  4. Give an analogy: An Agent without a dashboard is a car without a dashboard — you don't know the fuel, you don't know the rpm, you don't know when you'll stall. This is productization basics, not a nice-to-have.
⭐ Bonus point Turn this complaint into a project brief: even if only 30 seconds of those three minutes was an idle loop, multiply by call volume and it's a real bill. Observability pays for its own build cost.
Organize your answer using these lesson pages → Do you know what your Agent did? The real cost behind one message
Q28Tech Colleague
"The product needs to connect 10 MCP services. I was going to connect them all at startup so they're always ready. Users have been saying startup got slower — related?"
🎯 What they're assessing
They want to know whether you know the design called lazy connection, and whether you can see the availability risk in "connect them all." Slow startup is the surface. The real problem is that failures spread.
🧭 Answer framework
  1. Confirm the cause first: Connecting all 10 at startup means a few timeouts drag the whole launch. Real numbers from the course: connect-all at startup takes 30 seconds; after lazy connection, 0.2 seconds. Users feel instant open.
  2. Give three principles: Registering is not connecting — at startup you only declare which tools exist, you don't open network connections. Connect on first use — most tools may not be touched all day. Fault isolation — if one service dies, only that one tool is affected; the rest keep working.
  3. Name the product meaning: This isn't just a tech optimization. It's basic stability design. In connect-all mode, any third-party outage drags the whole product. Lazy connection locks the blast radius inside a single tool.
⭐ Bonus point Add a UX detail: a tool that can't connect should give a clear message and a retry entry when the user actually tries to use it. Don't dump the failure on every user at startup.
Organize your answer using these lesson pages → Lazy connection: don't connect until needed MCP is more than just "calling tools"
Q29Boss
"I saw a demo — the user said check my calendar, the AI noticed there was no calendar tool, and just installed one itself. That's insanely smart. Can we do that? Any risk?"
🎯 What they're assessing
The boss is half excited, half worried. You have to catch both ends: explain the self-configuration mechanism and the four safety designs it must ship with — no cold water, no blind hype.
🧭 Answer framework
  1. Explain the mechanism first: The traditional move is to error out as unsupported. The user has to find the MCP settings, fill in parameters, test the connection — most people never will. Self-configuration is the Agent matching a candidate tool to the need, asking the user once, and finishing setup after they agree. The bar drops from "can configure" to "can talk."
  2. Give four safety designs: Capability discovery — the Agent can only pick from a tool registry or a predefined candidate list; nothing of unknown origin gets installed. User authorization — must say what service it will connect, wait for explicit consent; the AI cannot connect in secret. That's the trust floor. Instant effect — hot-load after config, current conversation continues seamlessly. Safety boundary — sensitive tools like databases must be configured by an admin by hand, and stay out of self-configuration.
  3. Give the conclusion: We can, and we should. Self-configuration isn't letting the AI install plugins at will. It's automating a messy setup process, with the decision still in the user's hands.
⭐ Bonus point One sentence for the boss: the best tool management is the AI managing its own toolbox — but only after the user nods. The answer to "risk" is in that second half.
Organize your answer using these lesson pages → AI adds its own tools Lazy connection: don't connect until needed
Q30Boss
"A competitor shipped an AI assistant in two weeks. We've been at it two months and still haven't launched. They're just wiring a model to a chat box too, right? Where are we slow?"
🎯 What they're assessing
The boss is using the speed of a wrapper to pressure you on the value of productization. Answer badly and you look inefficient. Answer well and this is a chance to pack the whole chapter and tell it to the boss.
🧭 Answer framework
  1. Admit the surface first: Wiring a model to a chat box really can ship in two weeks. What users see is the tip of the iceberg: a chat UI, smart replies.
  2. Then talk about what's under the water: How you stop a stuck loop, how you compress context, whether you can delete the user's words, how you filter memory, how you grade permissions, whether you can see what the Agent did, what happens when a third-party service dies. These are the product decisions under the waterline. A wrapper product did none of them.
  3. Give the gap a dimension: Between a chat wrapper and a real Agent product, the difference is a hundred correct product decisions in places users never see. The same loop supporting N scenarios — the difference isn't the code, it's the decisions.
  4. Convert time into risk: The two months the competitor saved will be paid back after launch, one incident at a time: stuck loops, runaway bills, accidental deletes. We can cut scope and ship the core scenario first — but the under-the-waterline floor decisions cannot be skipped.
⭐ Bonus point Volunteer a middle path: list which decisions must be done before launch (safety, cost, fallback) and which can iterate after (memory, multi-Agent). Turn "slow" into a prioritized checklist.
Organize your answer using these lesson pages → Chat wrapper vs. a true Agent product Image generation productization checklist
One last piece of advice
The common thread across all 30 questions is accounting and risk containment: how to stop a loop, how to compress context, how to control the bill. Being able to explain these fluently proves you've truly walked the path from Demo to production. For anything you can't explain clearly, click the linked course pages to go back and fill in the gaps.

Why “Practice · From Demo to Product · 30 Tough Questions” can find relevant content

“Each with intent, framework, and bonus points: demo-to-launch gap / Agent deadlock / context compression / memory design / multi-Agent / MCP / cost accounting” moves retrieval beyond storing material: the real question is how to find what is relevant. That decision shapes the input quality of RAG, recommendation, and image-search systems.

Similarity is not the answer

In the flow described by “Each with intent, framework, and bonus points: demo-to-launch gap / Agent deadlock / context compression / memory design / multi-Agent / MCP / cost accounting”, embeddings place items in a comparable semantic space and a neighbor index narrows the search. The final answer still depends on whether the retrieved chunks cover the question, whether the distance metric fits, and whether the evidence is current.

  • Start with the conclusion: Getting the API working is only 10%. In real cases, going from working API to launch took three months. The gaps can be categorized across four dimension…
  • Experience layer: Generation progress feedback, one-click retry on failure, multiple results to choose from, history to revisit. In a demo, the user can sit and wait 30 seconds wit…
  • Safety layer: Dual content moderation (input and output), copyright risk, and privacy policy for user reference images. A demo can go bare; a production product that goes bare will…

Separate findable from relevant

Turn “Each with intent, framework, and bonus points: demo-to-launch gap / Agent deadlock / context compression / memory design / multi-Agent / MCP / cost accounting” into a small test: prepare queries with known answers, record relevance, misses, and distractors, then decide whether chunking, the index, or reranking needs to change.

Take the example one step further

The lesson starts with “Start with the conclusion: Getting the API working is only 10%. In real cases, going from working API to launch took three months. The gaps can be categorized across four dimensions” and then moves to “Experience layer: Generation progress feedback, one-click retry on failure, multiple results to choose from, history to revisit. In a demo, the user can sit and wait 30 seconds with no feedback; in a product, t…”. Reading those two pieces together makes the distinction clearer: which points are facts in the lesson, and which judgments depend on their conditions.

Carry the judgment into the next situation

The same logic applies to retrieval: define what counts as relevant, check whether recall covers the question, and then inspect whether ranking, chunking, or freshness pushed useful evidence out.

  • “Practice · From Demo to Product · 30 Tough Questions”: Start with the conclusion: Getting the API working is only 10%. In real cases, going from working API to launch took three months. The gaps can be categorized across four dimensions
  • “Take it further”: Experience layer: Generation progress feedback, one-click retry on failure, multiple results to choose from, history to revisit. In a demo, the user can sit and wait 30 seconds with no feedback; in a product, t…
  • “The closing point”: Map to the scenario: Return to the specific scenario in the PRD and explain which of the three it matches. If it matches, keep it; if it doesn't, cut it on the spot — that looks far better than defending an arc…

The final “The closing point” brings the discussion to “Map to the scenario: Return to the specific scenario in the PRD and explain which of the three it matches. If it matches, keep it; if it doesn't, cut it on the spot — that looks far better than defending an arc…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.

Mark as learned Your reading progress updates automatically
← PreviousNext →

Keep reading

The next useful article in the thread.

What You Can Do Now · Hands-onWire Up the First Real ToolA four-step demo of the tool-calling loop; three tasks: pick a tool, write a three-line description, run the loop and deliberately break it oncePractice Wrap-Up · FinaleChat Wrapper vs Real Agent ProductThe same loop powers N scenarios — the difference isn't in code, it's in product decisionsPractice Wrap-Up · RecapPractice OverviewImage generation, loops, memory, Prompt, multi-Agent, security, MCP — all connected in one diagramMCP in Practice · Deep DiveAI Adds Its Own ToolsAn Agent discovers it needs a new tool at runtime and configures MCP connections itself — the self-configuration approach

ARTICLE DISCUSSION

Leave one useful thought here.

Keep the idea that clicked, the question that stayed open, or a small note for the next learner.

↗
Discussing Practice · From Demo to Product · 30 Tough Questions From Working Demo to Useful Product
3discussionsArticle discussion · synced with the Circle
View in the learning circle
AM
Asha MorganContent editor
INSIGHTField note

I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.

ARTICLE DISCUSSION7 helpful
LH
Lin HarperIndie developer
INSIGHTInsight

After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.

ARTICLE DISCUSSION5 helpful
KM
Kiki MooreProduct operations
QUESTIONQuestion

When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.

ARTICLE DISCUSSION4 helpful