A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.
How to answer
The interviewer is checking that you know what the product does inside a customer’s systems, and that your concern turns into engineering habits. An answer that fits any company in the category fails.
- Name what the product touches. “Your agents read support tickets and can issue refunds through the customer’s billing API” sets up one risk list; “your platform joins an agency’s case records across departments” sets up another, where the risks are access beyond need and data used for a purpose nobody approved.
- Pick the two you would rank highest for the deployments you’d work on, say why, and give each a mechanism. Not “hallucination” but “the states a refund policy that doesn’t exist, and the customer is held to it”. Not “security” but “text in an inbound email is read as an instruction by an agent with write access”. Say who gets hurt: the end user, the customer or someone outside both.
- Give the field practice for each, as week-one work. Tool permissions scoped to the task, with irreversible actions behind human approval. An evaluation set built from the customer’s real cases before go-live, with a named owner after you leave. A tested way to switch the agent off.
- Say where your line is, knowing the deal pressure lands on you. Name the request you would refuse, such as removing approval on irreversible actions to hit a throughput target, and the person inside your own company you would escalate to, rather than a stand taken alone in front of the customer.
- Tie it to something they published about their own deployments. ElevenLabs’ post on lessons from its forward deployed engineering, for instance, names prompt ambiguity, tool misuse and escalation drift as recurring failure patterns in agent deployments. Source 1Building voice agents that last: some lessons learned from forward deployed engineeringPublisherElevenLabsSource typecompany blog Say which of your practices answers one of theirs, or where you would go further.
The trap is the op-ed: societal risks with nothing that changes what you build on Monday.
Follow-ups
What the interviewer may ask next, once your first answer is on the table.
- Which of those risks have you seen go wrong in something you deployed, and what did you change afterwards?
- A customer wants the human approval step removed to hit a throughput target. What do you do this week?
- Where would you disagree with how we handle one of these today?
Where answers go wrong
- Listing headline risks such as bias, misinformation or job loss with no mechanism, so nothing an engineer at a customer site would do differently follows from the answer.
- Handing the risk to someone else (“the policy team owns that”), so the field practice becomes “follow the guidelines”.
- Turning the question into praise by saying the company has already solved it.
Answer this in two minutes
Write the answer you would say out loud. The clock starts with your first word.
Illustrative answer about a fictional project
In this example, the company (an invented one) builds customer-support agents that answer customers by chat and email and act in the customer’s own systems: they look up orders, change delivery addresses and issue refunds through the billing system. “What your product touches decides the risks, so I’ll start there.