Hard AI PM interview questions

A growth prompt with a hard constraint. Three engineers rules out most ideas, and doubling usage also doubles the compute bill. The interviewer wants a funnel diagnosis and two or three bets that fit.

Tenfold growth is not an optimisation problem. The interviewer wants to see you find new users the product does not serve today, and protect reliability and margins while doing it.

The most common story in AI product development. A demo proves the model can do something; a product needs it to do that thing reliably on inputs nobody chose. The strong answer separates those milestones and resets expectations without losing the sponsor.

A craft question that separates PMs who have shipped AI features from those who have read about them. The answer is a document organised around failure modes, thresholds and evidence.

A design question with a regulatory constraint arriving halfway. The interviewer wants a useful product on both sides of it, and a clear line between preparing a decision and making one.

A strategy-sized design question. The tempting answer replaces the search bar with a chatbot. The scoring answer keeps fast keyword search for the shoppers who know what they want and uses AI for the shoppers who don't.

An emotionally loaded design question. The interviewer is watching for a product that actually helps, and for the judgment to see where companionship turns into dependency, manipulation or missed emergencies.

The failure every legal AI product fears. The interviewer wants a response that makes invented citations structurally impossible to present as real, not a promise to improve the model.

A convincing field score can conceal a wrong purchase order. Define the complete unit of work, preserve page and row evidence, and calculate the review queue before choosing autonomy.

Separate new-user and new-item problems, design a useful first session, and test whether early relevance survives beyond onboarding.

A prioritization score favors automated triage, but the data rights are unresolved. Separate a delivery commitment from a small experiment.

Shopkeepers want to know where their money is, in their language, without opening a dashboard. Start with answers that need no permission, add one-tap confirmed actions, and keep refunds and credit behind explicit approval.

Regulator field trials found automatic overdraft alerts cut charges by a quarter while opt-in alerts barely moved. Start with timely alerts on by default, fix categorisation, answer questions on demand and stay away from investment advice.

Repeat items are predictable; meal plans are a nice demo. Start with replenishment, expose ordering to outside assistants with one confirmation, and keep household preferences inside your own app.

Studies found drafts reduced burden without saving time, and some drafts could harm patients if sent unedited. Draft only low-risk message types, route urgent symptoms to people, and measure burden and safety.

A shared device has several users, some of them children, and no screen to confirm on. Lead with household coordination, make voice recognition optional, gate purchases and keep proactive prompts for the person they concern.

Continuous vision is useful and alarming to everyone the wearer looks at. Allow live vision only in sessions the wearer starts, enforce a visible indicator in hardware, refuse to identify people and lead with accessibility.

Accuracy and trust are different things. The feature saves no time if people double-check everything, and the fix starts with finding out why experts are cautious.

Approval screens fail in a predictable way: people click 'approve all'. The interviewer wants a design that focuses attention on the changes that matter and makes careful review fast.

Trust that outruns accuracy is as dangerous as distrust. The interviewer wants design that keeps experts engaged where it matters, without making the tool tedious.

Health assistants are useful exactly where they are risky. The interviewer wants clear tiers of what the assistant answers, how it handles emergencies and personal medical advice, and an experience that stays helpful instead of hiding behind disclaimers.

Trust is easy to survey and hard to measure. The interviewer wants a composite built from behaviour, interpreted carefully, and validated against outcomes the business cares about.

Translation is the smallest part of multilingual AI UX. The interviewer wants script choice, code-mixing, voice, cultural norms, and honest handling of languages where quality is weaker.

Personality can make an assistant pleasant or manipulative, memorable or annoying. The interviewer wants a personality that serves users' goals, stays honest about being an AI, and adapts when the moment is serious.

Licences are not adoption. The interviewer wants the real reasons people don't use the tool, and a plan that embeds AI into specific workflows with champions, measurement and honest pruning.

Faster speech can make a conversation take longer. Diagnose premature turns, design recovery after interruption and protect actions when a caller changes their mind.

Design an interruption policy from urgency and consequence, then measure useful action and attention cost beyond clicks.

Users rate flattering answers higher, so the launch metric points the wrong way. Build the measurement that catches it and decide what blocks a launch.

Benchmark gains do not cover what users built around the old model. Measure the behaviour that changed, give people a bridge and decide in advance when the old model goes.

Search visits with an AI summary produced 40% fewer outbound clicks in one large study. Decide which questions deserve a complete answer, which deserve a doorway and how you will measure the difference.

Hiding the bot is off the table in many markets and was never a good bet. Disclose on the first turn, then win back the lost sales by testing how you disclose and what the assistant does next.

Reasoning traces often leave out what drove the answer, and explanations make people accept wrong answers more. Show progress and evidence, and decide who gets the full trace.

Models sometimes describe actions they never took. Let the system decide what is done from checks it runs itself, and show users the evidence.

At a 0.05% base rate, a classifier that is right 99% of the time on safe messages still flags about twenty people who are fine for every one in danger. Build a ladder of responses that each fit their error rate.

The strategy question every AI application company faces. 'Better prompts' is not an answer. The interviewer wants a ladder of defensibility and a plan to climb it.

Platform risk made real. The answer is neither panic nor dismissal: work out which customers are actually at risk, double down on what the provider cannot easily do, and reduce dependence where it matters.

A high-stakes strategic question where the answer is usually no, but not always. The interviewer wants the real goal behind the request, the economics, and a recommendation the CEO can accept.

Generous terms now, constraints later. The interviewer wants the value of the offer weighed against the cost of losing optionality, and a counter-proposal that keeps the benefits without the trap.

AI features commoditise fast because everyone can access similar models. The interviewer wants a move from feature advantage to workflow, data and outcome advantages, with a plan for the feature itself.

The innovator's dilemma in SaaS form. If you don't ship the AI, competitors will; if you do, per-seat revenue shrinks. The interviewer wants a pricing and product transition that grows revenue with the work done.

Matching free is tempting and often ruinous when every use costs money. The interviewer wants a segmented response that protects the customers you can keep, the margin you need, and the value only you deliver.

A portfolio question. Spreading money evenly guarantees mediocre results; betting everything on one idea risks it all. The interviewer wants a portfolio with evidence gates, staged funding and kill criteria.

Interrogate an impressive capability claim, choose a buyer and price the cost of being wrong before proposing a launch.

The partner brings more paid accounts but retains part of every payment. Compare contribution and acquisition payback, then negotiate the dependency behind the spreadsheet.

The assistant owns the user, the ranking and the payment rules. Ship a narrow app for discovery, keep the account and core workflow on surfaces you own, and measure incremental conversions with a holdout.

Pay for content that measurably improves answers, in the form that matches how you use it: per use for grounding, flat licences for unique training data, and nothing for sources that don't move quality.

Figma reported exactly this drop, driven by AI hosting costs, and moved to enforce credit limits. Find which features and customers cost the margin, meter heavy use, and keep margin only where AI does not buy retention.

Enterprise vendors have released models under MIT, Apache and non-commercial licences. Release when the model complements what you sell, pick the licence that matches the goal, and keep the workflow-tuned versions closed.

Two Indian telecom deals put AI subscriptions in front of hundreds of millions. Take it only with a cost cap, success measured on active users, and a billing and consent handoff agreed at signing.

Large companies have delayed EU launches for different reasons. Name the specific blocker, ship the subset that clears it, and set dated exit criteria for the rest.

Default placement buys reach, not users. Pay for activated users rather than shipped devices, refuse exclusivity, and gate renewal on activation and retention.

Model prices do rise. Measure the margin hit, evaluate alternatives now, route only the tasks that need the expensive tier, and treat model price as a supplier term you negotiate and hedge.

A larger context window changes what fits in a request. Decide whether to use it by checking corpus size, freshness, permissions and cost per successful query, including cache misses.

Retrieval failures look like model failures to users. This question tests whether you can locate the failure precisely and choose fixes in the order that pays, rather than swapping models.

A puzzle with a precise answer. Price per token is only comparable if a token means the same thing, and across model generations it often does not.

A design trade-off with cost, accuracy and latency all pulling differently. The interviewer wants a measured comparison on real receipts and a hybrid that sends each image down the cheapest path that works.

A trade-off question where both sides have serious arguments. The interviewer wants the dimensions that decide it, and a recommendation that depends on facts you would go and get.

A question about fairness and unit economics hiding in a tokenizer. The interviewer wants the mechanism, the arithmetic, and options that do not leave non-English users with a worse product.

Many enterprise RAG failures happen before retrieval: the system never read the document correctly. The interviewer wants you to find the parsing problem and fix it at the right layer.

A quality problem with a technical cause and a product solution. The strong answer explains why long contexts degrade and designs conversation management rather than hoping a bigger window fixes it.

Use feature parity, time-aware holdouts and delayed outcomes to decide what needs fixing before requesting another training run.

Choose a training objective from observed failures. Separate preference labels, demonstrated answers and adapter methods from factual grounding.

Choose a churn intervention from a fixed outreach budget. Compare the models at that capacity, explain the error costs and decide where language processing could help.

Turn confidence scores into a defensible approval policy. Work through selective accuracy, uncertainty, correlated errors and review capacity before deciding which invoice fields can bypass a human.

Shorter and binary embeddings cut storage by orders of magnitude and lose a few points of retrieval. Decide with recall on your own queries and a rescoring step.

Sending the whole video with every question costs about a quarter of a million tokens. Index it once, retrieve the right minutes and keep the whole-video pass for one-off questions.

Hundreds of examples in a cached prompt can match fine-tuning and let you change behaviour in minutes. Price both, then decide by volume, latency and how often the examples change.

Two well-run teams published opposite defaults. Decide by repository size, how fast code changes, latency and whether customers will let you store embeddings of their code.

Aliases move, providers change infrastructure and retired models get re-routed. Pin versions in production, watch continuously and treat every model change as a release.

Translation through English helped low-resource Indian languages and hurt Hindi in one benchmark. Route by language, protect what must not be translated and measure on your own customers' messages.

A RAG pipeline is the obvious first sketch. A strong answer starts with permissions instead, because one leaked salary document ends the product.

A full-stack AI system design with scale, money, languages and angry customers. The interviewer wants tiers: cheap triage for everything, an agent where it pays, and humans where it matters, with the cost per day worked out.

Latency-dominated system design. A suggestion that arrives after the developer has typed the next characters is worthless, so every design choice is about milliseconds, context and cost per keystroke.

A deadline you did not choose and a change that touches every output. The interviewer wants a plan that treats API compatibility and behavioural compatibility as different problems.

A design question with a constraint dropped halfway. The interviewer wants to see residency flow through every component: model calls, logs, caches, embeddings, evals and support access.

A large-scale design question where every error is someone's real harm: harmful content left up, or legitimate speech taken down. Strong answers tier by severity and confidence, keep humans in the hard cases, and measure both kinds of error per language.

Search plus generation at consumer scale. The design has to deliver fresh, cited answers in a couple of seconds, resist manipulated pages, and keep cost per query viable.

A cost lever that can silently serve wrong answers and leak one user's data to another. The interviewer wants the failure modes and a design that keeps the savings where they are safe.

A lawyer will not trust a summary. Design clause extraction, playbook comparison and cited deviations, with a measured miss rate on the clauses that carry liability.

The model is one box. Prompt and output filters, brand and rights rules, provenance labels, cost per kept image and a queue for peak hours decide whether the feature works.

Putting a large model in the search path can improve relevance and blow the latency budget. Use a cascade, rerank only where it helps, cache, and measure on judged queries and live tests.

Define what unread means, preserve edits and permissions, and make every action item traceable. The design must tell users when the summary covers only part of their inbox.

A model wins on connected tasks but leaves field staff without help during outages. Compare all scheduled work, then defend local data, expiring permissions and synchronization.

Twenty thousand calls a day, two languages and a telephone network you do not control. Scope the intents, budget every millisecond and price the handoff before you promise containment.

Open schema access answers more questions and produces more wrong numbers that look right. Choose the scope, the permissions and the evidence each answer must show.

The token bill drops by two-thirds and failures rise by one point. Price the failures before you call it a saving, and check what routing does to your cache.

Stuffing every past conversation into context is expensive and still forgets. Decide what becomes a memory, how deletion cascades and how you test updates and forgetting.

Students solve more practice problems with an AI that gives answers, then score worse on the exam. Decide what the tutor may reveal, how it gets the maths right and what you will measure.

Accept rate can rise 28% while accepts stay flat. Define the reward, correct for what users never saw and decide whose data you may train on.

Cropping beats a bigger model, a smaller embedding buys back latency, and a stale index sends shoppers to items they cannot buy. Make each of those calls with numbers.

The compounding arithmetic every agent PM should be able to do in their head. Once you show 0.95 to the tenth power, the interviewer wants to know which of four levers you would pull first.

Money movement is where agent design stops being theoretical. The strong answer never lets the model be the control, and shows exactly where policy, approval and idempotency sit.

Multi-agent diagrams look sophisticated in a design review. The interviewer is checking whether you can name the specific conditions that justify them and the costs they add.

Memory makes assistants feel personal and creates a new way to be wrong, creepy or unsafe. The strongest answers start with what should never be remembered.

Agent output is cheap; human review is not. This question tests whether you measure the agent by what it costs the team to accept its work, not by how much work it produces.

A range is not a pricing input. Work out cost per accepted task by effort level and cost per account by cohort, compare flat, allowance and usage plans on the same customers, then say what would change your choice.

A stakeholder question wrapped in an agent question. The strong answer protects the deal and the customer by turning a capability promise into an outcome commitment with a path.

An incident question where the root cause is almost never 'the model made a mistake'. The interviewer wants containment first, honest communication, and a fix to the permission design that made deletion possible.

Two problems hide in one complaint: the agent is slow, and waiting for it feels worse than it needs to. Strong answers attack both, and question whether every task should make the user wait at all.

A timeout does not tell you whether money moved. Define the recovery states, retry contract and customer messages that prevent a helpful agent from issuing the same refund twice.

A smooth demo on ten claims proves little. Build a task-level evaluation on a test copy, price wrong entries against staff time, and launch with review before submission.

Delegated spending needs a mandate the user sets, limits enforced outside the model, merchant and price checks, and a clean way to undo. Decide where confirmation stays.

An approval can arrive after the worker has restarted. Choose a runtime from that requirement, show its recovery behavior and avoid repeating a purchase after a timeout.

A canceled chat stream leaves work running in three services. Define the user promise, reconcile actions already sent and test the race at the execution boundary.

Agent checkout protocols keep the merchant as merchant of record, but disputes and customer ownership move. Integrate one protocol through your payment provider, start small and price the risk.

Borrowing the creator's full access is the default that causes incidents. Give unattended agents their own identity with narrow scopes, an owner and an expiry, and keep delegation for interactive work.

Experiments show agent buyers favour whoever answers first and can be redirected by injected text. Allow structured exchange, treat the other agent as untrusted and keep hard limits outside the model.

The headline horizon is a 50% success rate on someone else's tasks. Plan on the 80% horizon for your own tasks, break long jobs into checkpoints and keep long-autonomy features as dated bets.

Agents outlive their creators and keep their access. Make registration the price of connecting to data, give every agent an owner and an expiry, and keep a kill switch, without pushing builders to tools you cannot see.

Slack allowed permission-checked search and banned bulk export, indexing and training by outside apps. Decide what access serves customers, what protects them and what keeps your own AI features competitive.

Voices can be cloned and caller ID can be spoofed. Make verification a deterministic tool call that gates which actions the agent can reach, with stronger factors for money and addresses.

A US appeals court treated a shopping agent as the user's tool, and bot-management networks now sign agent traffic. Offer a sanctioned path for identified agents, apply step-up checks to anonymous automation and measure fraud by traffic type.

Models rarely ask unless told to, and research shows asking at the right moment raises success substantially. Ask when the answer changes the outcome and the action is costly, batch questions up front, and measure both kinds of error.

Decide which support tasks an agent can safely own. An 82% pass rate needs a denominator, a breakdown of failures and a comparison with today's service.

95% agreement sounds like a yes. On its own the number says almost nothing, and the thirty-second arithmetic that proves it is what separates a launch gate from a dashboard.

A diagnosis question with five plausible causes. Strong candidates rank them by likelihood and name the cheapest check for each instead of reciting all five.

Calculate the evidence needed for a small quality gain. Running both models on the same cases changes the test; the disagreement counts determine whether pairing saves evaluation work.

Agent evals are where answers that worked for chatbots stop working. A correct final booking can hide a path that broke policy, spent money twice or took nine minutes.

Green dashboards and angry users at the same time. The strong answer treats the complaints as evidence about the eval, not noise to explain away.

An eval nobody runs is worth nothing. This question tests whether you can do the cost arithmetic and redesign the workflow, rather than ordering people to comply.

A translated English eval set can miss code-switching, transliteration and local support needs. Decide what to sample in each language and who can judge the replies.

A larger labelled set can make a broken quality bar look more precise. Allocate a fixed review budget, resolve disputed criteria and decide which results can support a launch.

Choose an operating threshold using prevalence, error costs and review capacity. A good ranking score can still produce an unusable queue.

Separate reference overlap from faithful meaning. Build a decision from claim errors, omissions and the reader's task.

Single-turn test sets miss what breaks over a conversation: forgotten constraints, contradictions and drift. Build conversation-level cases, simulated users with goals, and session metrics.

Audit a judge's 68% win rate with an order-swap table. Separate stable wins from unresolved verdicts, declare the denominator, and test whether the result supports the product decision.

When a measure becomes a target, teams tune to it. Take eval scores out of targets, keep a sealed holdout teams cannot tune against, separate capability from regression evals, and tie OKRs to user outcomes.

Compare the same request with and without the profile, judged by people who see the profile, and test the three failures users notice: ignoring a stated preference, using a stale one and over-personalising.

A new judge is a new ruler. Run old and new judges in parallel on a human-labelled set, re-validate catch rates, mark the break in the trend line and pin judge versions from now on.

Accuracy alone rewards guessing. Set a penalty for wrong answers from what errors cost in your product, score both models under it, and the choice usually flips.

Short-answer benchmarks say little about ten-page reports. Check each statement against the source it cites, score coverage against an expert outline, test balance on contested topics and measure whether users act without redoing the work.

Published systems measure whether comments lead to code changes, aim for a precision target and filter non-actionable comments. Compare against human comments, seed known bugs for recall and run a randomised rollout.

An estimation question that tests commercial judgment. The inference bill is where the arithmetic starts; the number that decides the answer is somewhere else.

The cheap option per conversation is the expensive one per customer, until you read how the vendor defines 'resolved'. Two calculations, and the second one is where the offer is decided.

A margin question with a constraint added halfway through. The average user is not the problem; the distribution is, and a flat price hides it until the model gets more expensive.

AI metrics have unusually soft edges: what counts as an AI product, a resolution or an active user can widen without anyone announcing it. This question checks whether you audit a good number as hard as a bad one.

The candidate who says 'use a faster model' in the first sentence has already lost points. Decompose the budget, find the biggest bar, and check whether two seconds is the right target at all.

AI features are unusually good at producing engagement that is actually friction. The question tests whether you can tell the two apart in the data.

Caching is the cheapest large saving in most AI products, and a single line of personalisation at the top of the prompt can turn it into a 22% cost increase. The arithmetic is short; the layout insight is what scores.

The cost of the model is rarely the biggest number in this decision. The cost of a wrong answer is. One calculation makes the choice obvious in some products and wrong in others.

Design task evidence, privacy controls and a separate diagnostic path without pretending that minimal telemetry proves semantic correctness.

Separate saved meeting time from lost participation, and test outcomes at the team level when the feature changes shared behavior.

Turn a registered-user count into active usage, model calls and billable tokens. Compare an uncached baseline with a stated caching scenario without inventing a vendor quote.

A model release and a campaign happened together. Reconstruct the success rate, explain the mix shift and decide what evidence should drive the next change.

In one randomised trial, developers believed AI made them 20% faster while it made them 19% slower. Run staggered access on real work, measure time to merge and defects, and renew team by team.

The landmark study of AI in a call centre found the same pattern: big gains for new agents, small speed gains and small quality losses for the best. Report by skill tier and give experts a lighter mode.

Cheaper tokens bring longer prompts, more steps and more tasks, and some prices rise. Forecast spend as price times tokens per task times tasks times users, in bands, with caps per feature.

Generating more code moves the bottleneck to review, testing and release. Switch the scorecard to delivery metrics and put the next budget into review and testing capacity.

The security question every agent PM must answer well. Anyone can send your user an email, which means anyone can put instructions in front of the model. The strong answer stops trying to make the model resist and limits what a fooled model can do.

Hiring is one of the clearest high-risk uses under the EU AI Act. The interviewer wants to see you turn obligations into product requirements and a roadmap, with dates stated carefully.

A textbook confused-deputy attack on a powerful agent. The interviewer wants the mechanism, the full set of controls (sandbox, network, secrets, approvals), and a response plan for the disclosure.

US AI regulation is a moving patchwork on top of long-standing lending law. The interviewer wants a product plan that holds up whichever way state laws go: explainability, fairness testing, human review and documentation.

IP risk in generative products comes from four directions: what the model was trained on, what users put in, what comes out, and what the contracts say. The interviewer wants all four and practical controls, without pretending the law is settled.

A safety question where good intentions are not enough. The interviewer wants age-aware design, specific policy changes, crisis handling, parental controls that respect teens, and measurement.

Fairness questions punish vague answers. The interviewer wants specific metrics, an awareness that they conflict, the data you need, and what you would change in the product when the numbers look wrong.

Explainability becomes concrete the moment a regulator or a customer asks about one decision. The answer depends on what was logged, how the decision was made, and whether a person was involved.

Every connected server is code you did not write, holding credentials you issued, describing tools your agent will trust. Write the approval checklist and the runtime controls.

Untrusted pages, private data and the ability to act or send are each manageable alone and dangerous together. Set a rule for combinations, then decide where a person must confirm.

Both countries now require visible labels and embedded markers on synthetic media, with different details. Build one pipeline that satisfies the stricter of each, and keep your own export path from stripping it.

Regulators have acted on exactly this, and two laws set 48-hour takedown clocks. Block sexualised edits of real people by default, apply the same rules to paid users and build takedown that meets the clock.

Self-declaration does not count in the UK, and US courts have upheld state age-verification laws. Combine age estimation with step-up verification, default to the safer experience and block where no compliant method exists.

Public is not the same as free to use. In the EU you need a legal basis and an objection route; in India the exemption covers data the person made public themselves, which is narrower than anything on the web.

The UK regulates AI through existing laws, and the Online Safety Act's reach over chatbots depends on what the product does. Map features to duties, and build for powers that are already being extended.

A launch question where positioning, pricing, evaluation and capacity all have to line up. The interviewer wants to see you avoid cannibalising the wrong tier and give developers what they need to adopt it.

Quantization offers large savings with small average quality loss, and the averages hide where the loss lands. The interviewer wants evaluation on real workloads, by segment, before any cost win is claimed.

The spreadsheet comparison everyone gets wrong by assuming full GPU utilisation and forgetting the team. The interviewer wants a break-even with honest utilisation, operating costs and a quality check.

A serving optimisation whose value depends on traffic shape. The interviewer wants the mechanism, the evidence that gains shrink under load, and a decision tied to the product's latency and throughput needs.

API pricing shapes which products developers can build. The interviewer wants tier spread, input and output pricing, discounts that reward efficient usage, enterprise commitments, and predictability.

A resource allocation question with no painless answer. The interviewer wants a transparent framework, efficiency gains before rationing, and decisions leadership can stand behind.

English-only evaluation hides regressions that land on most of the world's users. The interviewer wants a plan that covers languages by importance, uses native evaluation, and gates release on per-language results.

Model latency depends on input length, output length, load and the model itself, so a naive guarantee is either meaningless or impossible. The interviewer wants a guarantee that is defined precisely, measurable and backed by capacity.

Budget for the whole labeling job, distinguish disagreement from poor work and test whether the resulting data improves the model.

A vendor has more rows, while an internal pilot has higher accepted yield. Compare usable evidence, uncertainty and the work hidden in the quote.

Regional capacity is fragmented capacity, and four providers charge about 10% for it. Price it, define exactly what you promise, and tell customers which models arrive late in their region.

Two labs moved from capacity commitments to a pay-per-token fast mode. Decide what speed means, how you stop the fast lane being swamped and who still needs reserved capacity.

Zero retention and abuse monitoring pull in opposite directions. Offer eligibility rather than a switch, automated review without storage, customer-held storage, and be honest about which models and features are excluded.

Routing as a platform feature saves customers money and moves quality decisions onto you. Make it opt-in, show which model answered, bound the quality loss and never change the model set under production traffic.

One major provider wound down its evals product and pointed customers to an open-source tool; others keep investing. Decide based on whether evals drive model usage, and on whether customers want evaluation tied to one vendor.

Server-side state simplifies integration and can improve caching, but it means storing data and it does not make old tokens free. Offer it as an option with short retention and give zero-retention customers an equal stateless path.

A worked live-round walkthrough. The trap is building a pretty summariser. The scoring path is a narrow extractor with structured output, a small test set that probes the hard cases, and an honest readout.

The handoff is where many AI prototypes die or get rebuilt wrongly. The interviewer wants the artefacts that carry learning forward and a clear list of what the prototype did not prove.

Text-to-SQL demos are easy and dangerous. The interviewer wants the controls that stop wrong numbers, data leaks and runaway queries, and a design that makes answers checkable.

Agent prompts tempt candidates into ambitious builds that collapse. The strong answer builds the least autonomous version that demonstrates the idea, with mocked tools, clear limits and tests of the hard paths.

Prototypes tested in English hide most of what goes wrong for users in other languages. The interviewer wants a prototype cycle that tests real speech and text from target users, with native evaluation.

A working prototype is the start of the decision, not the end. The interviewer wants evidence on value, feasibility at real quality, cost, risk and strategic fit, and a decision rule set before the evidence arrives.

RAG is the most common live-build topic. Strong candidates choose the simplest approach that works for 30 documents, make citations real, and test retrieval and answers separately.

Asked of senior candidates who will run these rounds, and useful for anyone preparing. Knowing the rubric from the interviewer's side shows what to optimise for.

The tool choice is the easy part. Interviewers screen for how you decide on evidence, what you allow near code and data, and how you stop prototypes becoming unowned production code.

Both sides are partly right. The scored answer finds the part of the spec that can be exact, makes the rest measurable, and gives legal something they can actually sign.

A tenth of apps in one audit exposed their database to anyone. Check access control on every table, keys in the client, auth with a second account and an owner for the findings before any customer sees the link.

Companies that shipped MCP servers exposed reads widely and held back money-moving actions. Start with a few consolidated read tools, test descriptions against real tasks, and gate anything irreversible.

The test is choosing what to build, not building fast. Name the riskiest assumption in your own case, build only the slice that tests it and say what result would change your recommendation.

A prototype became something people depend on, on a platform with a shutdown date. Triage it, export the prompts and configuration now, name an owner, and rebuild only if usage justifies it.

A behavioural question with a technical core: how you turned a readiness argument into agreed criteria and shared evidence, what you were wrong about, and whether the relationship survived.

A values question at AI labs and regulated companies. Panels want judgment about real risk, a constructive path forward, and courage without self-righteousness.

Classic roadmaps assume known capabilities. AI roadmaps must plan for capabilities that may arrive early, late or not at all. Panels want structure that keeps commitments honest and teams moving.

Overpromising is common in AI because demos impress and capabilities move fast. Panels want to see you reset expectations with evidence, protect the relationship, and fix the process that caused it.

Explain a disagreement in enough detail to show what you changed, what the researchers were right about and how you separated a research result from a customer commitment.

Crises reveal leadership. Panels want calm prioritisation, clear roles, honest communication, care for the team, and a lasting fix rather than heroics.

Ethics questions test judgment and courage together. Panels want a specific concern grounded in user impact, a constructive way forward, and honest reflection on the outcome.

AI launches increasingly run into legal, privacy and compliance review. Panels want a partner, not an adversary: someone who turns concerns into requirements and finds a path that works for both sides.

Turn conflicting pilot evidence into a recommendation an executive can approve. Show the decision, the rejected alternative, the workload cost and the evidence that would change your mind.

Make a past project inspectable: show the decision, your contribution and the limits of the result. Prepare for a reviewer who challenges both the metric and the design.

Bring one defensible workflow, show the review burden and explain a mistake that changed how you use the tool.

Panels want to hear that you did not average two signals. Show how you found out which one was measuring the wrong thing, and what you added to the launch gate afterwards.

Custom models are sometimes right and usually premature. Show a ladder of cheaper options, the evidence that would justify climbing it, and how you kept the customer while saying no.

AI costs vary by request, so pricing has to change, and people judge changes by fairness. Show the cost case, the communication and how you made it right when it landed badly.

A mandate is a direction, not a plan. Show how you translated it into measured outcomes per workflow, what you told people about their jobs and where evidence led you to push back.

Matching fast can cost more than being second. Show how you found out whether users would switch, what you shipped and on what quality bar, and how you held the line on the eval.