In this post12 sections
- Why ‘one small thing’ is the real test
- What hiring leaders say about yes and no
- Find out what drives the request first
- Trade, defer or phase: the scripts
- The change-request note
- Answering it live in the client round
- Mistakes: the silent yes, the flat no, the lecture
- The behavioral version: a time you said no
- Practice it against a customer who answers back
- Questions people ask
- Keep reading
- More from the blog
The interviewer is playing the customer’s product manager, and ten minutes in they say it: “While you’re in there, can you add one small thing?” You can feel the round turn on your next sentence, and you’re not sure whether they want to hear yes or no. The answer to a interview question is neither: find out what drives the request, show what it costs against what you already promised, then offer a trade, a deferral or a phased delivery, and name who decides. This post gives you the words for each, a change-request note you can write in the room, and the behavioral version. For the whole loop, round by round, read the FDE interview guide.
Why ‘one small thing’ is the real test
Scope creep rarely arrives as one big demand. It arrives as a string of small, reasonable asks, each too minor to argue about, which together move the date without anyone deciding to move it.
That is why it makes a good test. A single outrageous request is easy: anyone can refuse it. The “small thing” tests judgment, because there are two ways to fail:
- You say yes to everything, and the interviewer watches you promise work that can’t fit.
- You say no to everything, and refuse the real requirement, found late.
What the round rewards, in our reading, is the sorting: a clear yes where the request is sound, a priced trade where it isn’t, and the customer still on your side at the end.
What hiring leaders say about yes and no
Leaders who run forward deployed teams describe this exact skill.
Leo Mehr, a director of engineering at Ramp, wrote on Ramp’s engineering blog in August 2025 that 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 Note the first half. The yes is part of the skill, and it should sound enthusiastic, not grudging.
Sierra’s May 2026 post on its Strategist role says keeping deployments on track takes hustle and judgment, and it names pushing back on scope creep as part of that. Source 2Agent Strategist: Your PhD in applied AI (Andrew Kim)PublisherSierraSource typecompany blog The Agent Strategist is not an engineering title: the same post says strategists come from product management, engineering, consulting and other backgrounds. Source 2Agent Strategist: Your PhD in applied AI (Andrew Kim)PublisherSierraSource typecompany blog
OpenAI’s Colin Jarvis said on a South Park Commons panel in May 2026 that OpenAI’s unit works only about 10 engagements at a time and has to say no more often than yes. Source 3The Future of Forward Deployed Engineering | OpenAI, Ramp, Nominal, DatalandPublisherSouth Park Commons (YouTube)Source typerecorded talk or interview He was talking about which engagements to take on, not requests inside one, but the habit carries over.
The rest of this post turns that yes-and-no judgment into moves you can make out loud.
What these quotes are, and are not
They describe the work, not how any interview is scored; no employer publishes that. Use them to understand the target, not to quote at the interviewer.
Find out what drives the request first
Before you say yes or no, ask why. This move does more for your answer than any script.
In a July 2026 AI Engineer talk, Leo Mehr described a sales rep urgently demanding an integration, and said a well-trained FDE pauses to ask what is driving the urgency, who will use the integration, and whether all the workarounds have been exhausted. Source 4How Forward Deployed Engineering is done at Ramp — Leo Mehr (YouTube auto-generated English captions)PublisherAI Engineer, YouTubeSource typerecorded talk or interview Ben Kracker, a forward deployed engineer director at Salesforce, said on Salesforce’s blog in November 2025 that FDEs must peel back the layers of a request so they give customers the right solution rather than the one they asked for. Source 5Today's Hottest Role: Forward Deployed EngineerPublisherSalesforce 360 BlogSource typecompany blog
In the round, that becomes three short questions. Ask them in this order:
- “What’s prompting this now?” A new fact (a regulation, an audit, an executive’s question) changes what “done” means. A new idea usually doesn’t.
- “Who will use it, and what will they do with it?” A request tied to a named person and a decision is real. “It would be nice to see” is a wish.
- “What happens if it lands after go-live?” If the answer is “nothing much”, you’ve found a deferral. If it’s “the VP won’t sign off”, you’ve found a requirement.
The fictional customer is a freight broker. You’re deploying a document-extraction pipeline that reads bills of lading into their transport system, and go-live is next Thursday, with bill-of-lading extraction and a carrier scorecard in scope. Dana, their product manager, asks you to “also read the customs forms, since it’s the same kind of document”.
You ask what’s prompting it. Dana says the compliance lead flagged late customs filings last month and asked whether “the AI thing” could help. Who will use it? The compliance team, to catch missing tariff codes. What if it lands after go-live? “Compliance just wants to know it’s coming.”
Now you know three things: the need is real, the person who needs it isn’t the sponsor, and nothing on go-live day depends on it. That calls for a deferral or a phased delivery, not a no.
Trade, defer or phase: the scripts
Once you know the driver, pick one of three responses. These are our scripts, not anything an employer publishes. Each one says yes to the goal, prices the method and ends with a question.
| Response | Use it when |
|---|---|
| Trade | It matters for go-live, and something else can move |
| Defer | It’s real but nothing on go-live day needs it |
| Phase | Part of it is cheap now and the rest isn’t |
Trade: yes, if something moves
Say instead that Dana’s VP wants go-live to include a count of late customs filings, so the forms do matter on launch day. Then trade:
“Yes, I can have customs forms reading by Thursday if the carrier scorecard moves to the next release. The same people would spend those days building and checking the customs examples instead. Which one would your VP miss more on launch day?”
The trade names what moves, not how hard the work is. “It’s a lot of work” invites an argument about size. “The scorecard moves” invites a decision.
Defer: yes, after this date
“I want to do this for your compliance team, and I don’t want to do it badly. Customs forms have different fields and need their own set of checked examples, so they won’t be ready by Thursday without moving something that is. I’ll put them first in line after go-live and send you a sized estimate on Friday. Does that work for the compliance lead, or do they need something sooner?”
A deferral without a date is a polite no, and customers hear it that way. Always attach the day they will hear back.
Phase: a slice now, the rest later
“Here’s what I can do by Thursday: flag any shipment that has a customs form attached and send it to the compliance queue, so nothing is missed. The pipeline already sorts each document by type, so that’s a routing rule, about an hour, and nothing else moves. Reading the fields comes in the next release. Would that cover what compliance needs this month?”
Phasing can be the strongest answer, because it solves the problem behind the request today. It only works if the first slice is useful on its own; a slice that’s just the first half of a feature is a delay in disguise.
And the enthusiastic yes
Some requests should get a plain yes. If Dana asks for the pickup date, which the pipeline already extracts, to be added to the export, say so:
“Yes. We already read that field, so I’ll add it to the export today.”
Saying yes quickly to the cheap, sound request is what makes your no believable on the next one.
The change-request note
Whatever the customer chooses, write it down the same day and send it to the person who owns the date, not only the person who asked. Here is a short note for the customs request, in the shape we teach:
Change request: customs forms
From: Dana (product manager)
Need: compliance catches missing
tariff codes before filing
Option chosen: phase
By Thursday: flag shipments with a
customs form; route to compliance
Next release: read the form fields
Moves: nothing (routing rule,
about an hour)
Decided by: Priya (VP operations)
Next update: Friday, sized estimateThe rules that make it work:
- “Need” states the goal, not the feature. It keeps the talk on the outcome.
- “Moves” is never empty by accident. If nothing moves, say “nothing”. If something does, name it, so nobody is surprised later.
- “Decided by” names the sponsor. You recommend; the person who owns the outcome decides.
- One note per request, even the ones you decline. Over weeks, the notes show the pattern without you accusing anyone.
In the room, say the note aloud as you close: “Let me read back what we agreed, and I’ll send it to Priya today.”
The lesson Saying no, and holding scope builds this into a running change log across an engagement, including when to take a no above the person who asked. It’s in Pro.
Answering it live in the client round
Put it together. The interviewer plays Dana; you’re mid-way through a status update.
Dana: “Oh, and can it also read the customs forms? Same kind of document.”
You: “Before I say anything, tell me a bit more. What’s prompting it now?”
Dana: “Compliance flagged some late filings.”
You: “Who on compliance would use it, and what would they do with it?”
Dana: “They’d check for missing tariff codes before filing.”
You: “And if it arrived a couple of weeks after go-live, would that cause a problem on launch day?”
Dana: “Not really. They just want to know it’s coming.”
You: “Then here’s what I’d suggest. By Thursday, I’ll flag every shipment with a customs form and send it to compliance, so nothing gets missed. The pipeline already sorts documents by type, so that’s about an hour of work and nothing else moves. Reading the fields comes in the next release, and I’ll send a sized estimate on Friday. Does that work, or should we bring Priya in?”
Dana: “That works.”
You: “Great. I’ll write it up and send it to you and Priya today.”
Notice what’s missing: no “that’s out of scope”, no lecture, no promise you can’t keep. You asked before answering, priced the request, solved the real problem and closed with a written record. If the interviewer pushes (“it’s small, just do it”), don’t argue size. Say what it touches and what moves, then ask who decides.
The free question handle scope creep from a customer’s PM is this round with the pressure turned up: a new request on every weekly call and a pipeline that isn’t done. Try it out loud before you read the model answer. For how role-play rounds run in general, read the customer role-play interview, and for the questions to ask before any build starts, discovery call questions for engineers.
Mistakes: the silent yes, the flat no, the lecture
The silent yes. You agree to everything to keep the customer happy. In a role-play, the interviewer then asks “so will Thursday still hold?” and you have no good answer. The fix: never say yes without saying what it costs, even when the cost is nothing.
The flat no. “That’s out of scope.” It ends the conversation. The customer hears that you care about the contract, not their problem. The fix: yes to the goal first, then the method you won’t use, then what you’ll do instead.
The lecture. You explain scope creep to the customer, or tell them how projects should be run. The fix: show the pattern with the change-request notes, flatly, and let the sponsor draw the conclusion.
Arguing about size. “It’s not small, it’s at least three days.” Now you’re negotiating an estimate, and they’ll negotiate it down. The fix: name what moves.
Deciding for the sponsor. You pick the trade yourself because it seems obvious. It may be, but it isn’t yours to pick. The fix: recommend, then ask the person who owns the date.
Skipping the why. You go straight to a trade on a request that turns out to be the thing the sponsor will judge the project on. The fix: the three questions, every time.
Before your client round
- I can ask “what’s prompting this now?” without sounding defensive
- I have a trade, a defer and a phase script I can say from memory
- I end every answer with who decides and when they hear back
- I can dictate a change-request note in under a minute
- I have one example ready of a request I said yes to quickly
The behavioral version: a time you said no
The same skill shows up as a story question: tell me about a time you said no to a customer or senior stakeholder. That question also asks what the relationship looked like a month later, so prepare that half as carefully as the no itself.
Structure the story around the moves above:
- The request, and why it sounded reasonable. If it was plainly absurd, there was no judgment to show; pick a different story.
- What you asked to find the driver, and what you learned.
- The cost you showed, in terms of what would move.
- The alternative you offered: the trade, the deferral or the phase.
- Who decided, and how you wrote it down.
- What the customer did next. Evidence, not “we stayed on good terms”: they renewed, they asked you into the next project, or they brought you the next request early so you could size it.
Two neighbors are worth preparing too, both in Pro: a request marked urgent that turned out not to be, and two customers who want things that can’t both be built. When the no is about a date rather than a feature, how to tell a customer the project is late covers the conversation.
Practice it against a customer who answers back
Reading scripts is not the same as saying them to someone who pushes. Say the three questions and one script of each kind out loud tonight, and end each one on the four-part close from the free client-round lesson.
The free practice case puts you in front of an AI customer, a city whose mayor has already promised an AI review tool, that reveals facts only when you ask the right question. It is the same move as finding the driver behind a request before you commit. It’s free with a sign-in, and the score quotes your own words back to you.
Questions people ask
How do you answer a scope creep interview question?
Acknowledge the request, ask what is driving it, then show its cost against the current commitment and offer a trade, a deferral or a phased delivery. End with who decides and by when, and write the decision down.
What do hiring managers want to hear about saying no to a customer?
That you can tell a reasonable request from an unreasonable one. Leo Mehr, a director of engineering at Ramp, wrote that FDEs must say 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
What is scope creep?
Scope creep is work added to a project after its scope was agreed, usually a request at a time, without a matching change to the date, the team or what gets cut.
Keep reading
Lessons
Questions
- The customer’s product manager adds a new dashboard request on every weekly call, and the core pipeline is not done. Handle this week’s call.
- Tell me about a time you said no to a customer or senior stakeholder. What did the relationship look like a month later?
- Tell me about a customer request marked urgent that turned out not to be. How did you find out what was really driving it?
- Two customers asked for things that could not both be built. How did you decide, and how did you tell the one who lost?
More from the blog
Interview rounds
How to tell a customer the project is late: the interview answer and the real email
A structure for telling a customer the project is late: the spoken answer, the follow-up email, and the phrases that make it worse.
Interview rounds
A customer says requests are failing: how to run the first hour in an FDE interview
A customer says requests are failing. Your first hour in the FDE interview: scope, timeline, recent changes, error classes, rollback and the update.
Interview rounds
Discovery call questions for engineers: what to ask a customer in the first meeting
What to ask a customer in the first meeting, by outcome, users, data, systems and constraints, with follow-ups that turn vague answers into requirements.