A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.

How to answer

Anyone can describe a refusal. This question also asks what the relationship looked like a month later, so the story needs a no that held and a relationship that held too.

Leo Mehr’s August 2025 post on Ramp’s engineering blog says FDEs must be able to give an enthusiastic yes to rational customer requests while pushing back against unreasonable ones. Source 1Forward Deployed Engineering (Leo Mehr, Director, Engineering)PublisherRamp Builders (engineering blog)Source typecompany blog The story you pick should show you can tell the two apart under pressure from someone senior.

Five parts, and the last one is the half most answers skip:

  1. The request and the person. Who asked, how senior, what they wanted and by when. Make the request sound reasonable, because it probably was.
  2. Why no, in their terms. Tie the refusal to their own goal, not your workload. “This would put the number you’re taking to the board at risk” beats “we don’t have capacity”.
  3. How you said it. Live before written, and the words you used.
  4. The alternative. The smaller thing, the later date or the trade you offered, what it cost you, and what part of the request stayed refused for good.
  5. A month later. Something they did: what they asked you for next, whether they came to you directly, whether your alternative shipped and got used.

The same shape works at an AI company. A customer VP asks you to let the support issue refunds on its own before the eval set covers refunds. The no in their terms is “one bad refund in the pilot ends the pilot”, and the alternative is that the agent drafts, a person approves, and you report the approval rate every week.

Quote your no as you said it. The interviewer is judging your tone, and a paraphrase hides it.

Hold back the full analysis behind the no. One sentence of reasoning in their terms is enough; if the interviewer wants the rest, they will ask what would have made you say yes.

The traps: a no that was really a yes with a delay, a request so unreasonable that refusing took no judgment, and a relationship half with no evidence (“we’re still on good terms”). If the relationship took a hit before it recovered, say so; that is more believable than a no nobody minded.

The no that offers a path, trading scope for date and when to escalate a no are taught in Saying no, and holding scope, in Pro. It is part of Client simulation and customer judgment, whose first lesson, what customer rounds look like, is free.

GlossaryAgentA system in which a model chooses steps and tool calls to complete a task, within limits the design sets.More on Agent

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

  • What would have made you say yes?
  • Did anyone go over your head after you said no, and what happened?
  • What did the alternative you offered cost you or your team?

Where answers go wrong

  • Describes a no that was really a yes with a delay, or a no to a request that was plainly unreasonable, so there was no judgment to show.
  • Answers the relationship half with “we’re on good terms” and no evidence of what the customer did next.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Two minutes

Compare with the model answer

Illustrative answer about a fictional project

Written in the first person to show the structure. Tell yours from your own work.

I was deploying supply forecasting for a hospital network, sponsored by the CFO, who wanted fewer stockouts and less expired stock written off before the board review that fall.

Two weeks before go-live, she emailed asking us to let department heads override any forecast directly; several said theirs looked wrong, and she wanted to head off a revolt.

Unexplained overrides would flow straight into orders and blur the comparison between the forecast and the old par-level process, which was the number she was taking to the board. So instead of replying, I asked for 20 minutes and said: “I don’t think we should ship overrides before go-live, and I want to explain it in terms of your board number, not our schedule.” Then the reason, in one sentence: “If department heads can override without a reason, what you show the board becomes the forecast plus whatever people typed, and you lose the comparison you’re presenting.”

I offered a flag button on any forecast, with a required reason. Routine flags reached a supply chain analyst within one working day; an urgent flag paged the on-call analyst, who could change that day’s order directly and log why. I also offered to present it to the department heads myself. She accepted, not happily, and her next two emails were copied to my manager. The alternative cost us a week of analyst on-call cover, and me two evenings rebuilding the go-live deck.

A month in, department heads had sent 140 flags; one exposed a surgical ward’s usage history split across two location codes. Stockouts in the pilot units were 38% lower than in the units still on par levels over the same weeks, and that was the comparison the CFO took to the board. She asked me, not the account manager, to scope phase two.

What she first asked for, unexplained overrides going straight into orders, never shipped: phase two overrides needed a reason code and were logged beside the forecast.