By FDE Interview Prep, a SourceStrongAI company

In this post11 sections
  1. Why the first meeting decides what you build
  2. Outcome: what has to be true when this works
  3. Users and workflow: who touches it and how
  4. Data and systems: what exists, who owns it, how fresh it is
  5. Constraints and the decision process
  6. Turning a vague answer into a requirement
  7. Who owns discovery in FDE postings
  8. Using the list in a client or decomposition round
  9. Questions people ask
  10. Keep reading
  11. More from the blog

You’re about to sit across from a customer for the first time, on the job or in a client round where the interviewer plays the customer. Whatever you learn in that meeting is what you build on. Miss the question about who owns the data, and you find out in week three, when the export you designed around turns out to be a spreadsheet someone updates by hand. For how the client round fits the whole loop, read the FDE interview guide.

The short answer: ask one question from each of six groups, in order.

  1. Outcome: “When this works, what is different six months from now?”
  2. Users: “Who reads these emails today, and what do they do next?”
  3. Data: “Where does it live, who owns it, how fresh is it?”
  4. Systems: “What must this connect to, and how do your users sign in?”
  5. Constraints: “What must security see before go-live, and is there a hard date?”
  6. Decision: “Who decides this is done, and who can stop it?”

Follow every vague answer with a question that pins it to an example, a number or a name.

Why the first meeting decides what you build

A customer arrives with a request, not a requirement. “We want AI to answer our order-status emails” sounds clear until you ask where order status lives, and three people give three answers.

The gap between the request and the reality is the job. The Pragmatic Engineer reported, in August 2025, that Colin Jarvis, then OpenAI’s head of forward deployed engineering, said that what customers describe in scoping often does not match the data and system reality, so his team biases toward moving fast and adjusting the scope. Source 1What are Forward Deployed Engineers, and why are they so in demand? (Gergely Orosz)PublisherThe Pragmatic EngineerSource typenews report

The enterprise side says the same thing in different words. Ben Kracker, a director at Salesforce, said on Salesforce’s blog in November 2025 that FDEs must “peel back the layers of the onion” to find what is at the core of a request, so they can give customers the right solution rather than the one they ask for. Source 2Today's Hottest Role: Forward Deployed EngineerPublisherSalesforce 360 BlogSource typecompany blog

Here is the example this post uses throughout. It is fiction.

A regional building-supplies distributor. The VP of customer operations says: “Our service team drowns in ‘where is my order?’ emails. We want AI to answer them.”

Outcome: what has to be true when this works

“AI for emails” is a feature. The outcome is what changes for the business.

Ask:

  • “When this works, what is different six months from now?” You want a change you can see: fewer emails handled by people, faster replies, fewer escalations to sales reps.
  • “How do you measure that today?” If nobody measures it, your first deliverable may be the measurement.
  • “Have you tried to fix this before? What happened?” A failed attempt tells you where the landmines are.
  • “What’s driving the urgency now?” (Mehr’s question, below.)
  • “What happens if we do nothing?” This tells you whether anyone will fight for the project.
  • “What would make you call this a failure?” Failure is often easier for a customer to picture than success. A wrong delivery date sent to a contractor may cost them more than a slow reply.

When the VP says “faster responses”, ask “faster than what, and measured where?” She says replies take most of a day and customers call the branch when they don’t hear back. Now you have a baseline to measure against and a second channel, phone calls, that the email bot alone won’t fix.

Our lesson on stakeholders and success metrics, in Pro, teaches you to pick one leading and one lagging metric and name who would dispute each.

Users and workflow: who touches it and how

The person who asked may not be the person who uses it. Ask:

  • “Who reads these emails today, and what do they do next?” Ask them to walk you through the last one they handled, step by step.
  • “How many of these arrive a day, and when do they spike?” Volume decides whether a person reviews every draft.
  • “Who else gets pulled in?” Here, the service rep emails the warehouse lead when a pick is late. That handoff is the slow part.
  • “What do they do when the system is wrong?” Workarounds show you where the data can’t be trusted.

Leo Mehr, a director of engineering at Ramp, said in an AI Engineer talk published in July 2026 that when a sales rep urgently demands an integration, a well-trained FDE pauses to ask what is driving the urgency. Source 3How Forward Deployed Engineering is done at Ramp — Leo Mehr (YouTube auto-generated English captions)PublisherAI Engineer, YouTubeSource typerecorded talk or interview He said the FDE also asks who will use it and whether all workarounds have been exhausted. Source 3How Forward Deployed Engineering is done at Ramp — Leo Mehr (YouTube auto-generated English captions)PublisherAI Engineer, YouTubeSource typerecorded talk or interview

For the distributor, the walkthrough changes the design. Reps answer the easy emails by copying a line from the order screen, but orders stuck in the warehouse need a person who can call the branch. So version one drafts replies for the easy cases and routes the stuck ones to a named queue.

Data and systems: what exists, who owns it, how fresh it is

This is where the description and the reality part ways. For every piece of data the solution needs, get four answers: where it lives, who owns it, how fresh it is and how you get access.

  • “Where does order status live?” The distributor’s answer: order lines in the ERP, pick and pack status in the warehouse management system, and tracking numbers in a carrier portal.
  • “Who owns each one?” An owner is a person who can grant access and explain a strange value, not a department. Here, Maria, the ERP administrator, owns order lines; the warehouse lead owns pick status.
  • “How fresh is it?” The data warehouse the analytics team offers refreshes overnight. A customer asking “has it shipped?” in the middle of the afternoon needs today’s status, so the warehouse copy alone is not enough.
  • “Can I see ten real examples?” Ask for a sample, masked if needed, before you design. Look for missing tracking numbers, orders split across shipments, and status codes nobody can define.
  • “Can we have last month’s emails with the replies your reps sent?” That history is your test set: you can score drafts against real answers before anyone sends one.
  • “How do we get access, and how long does that take here?” A read-only database account, an API with a service user, or a nightly file drop are three different projects.

Then the systems questions:

  • “What must this connect to, and does it have an API?” Some older ERPs expose only reports or file exports.
  • “How do your users sign in?” If staff sign in through the company’s identity provider, the tool should use single sign-on, and the groups in that identity provider can decide which reps see which customer accounts.

A nightly warehouse and a live ERP API give you different products with the same name. Inputs: what data exists, who owns it, how fresh it is drills this mapping in Pro, and the question when customer data is worse than promised asks what you do when the sample shows the gap.

Constraints and the decision process

Constraints kill projects late when nobody asks early. Ask:

  • Security review. “What does your security team need to see before this goes live, and how long does their review take?” Expect to show a data flow diagram and where the model runs.
  • Data rules. “May customer names and addresses leave your network? May an external model service see them?” The answer can move the model inside their cloud or rule out a vendor.
  • Change process. “How does a change reach production here? Is there a change board or a freeze period?” A monthly change window sets your release rhythm.
  • Hard dates. “Is there a date this has to work by, and what happens on that date?” A peak season or a contract renewal is a real deadline. “The CEO asked” may not be.

Then the decision process, which is the easiest group to skip:

  • “Who decides this is done?” The VP sponsors it, but Dana, the service team lead, may be the one who says the drafts are good enough to send.
  • “Who can stop it?” IT security, the ERP owner and legal each hold a veto. Meet them before you build, not after.
  • “What would you need to see in two weeks to keep going?” This gives you the target for your first version.

The scope creep you fight in month two can start with a decision-maker nobody asked about in week one.

Turning a vague answer into a requirement

A requirement is something you could write a test for. Most first answers are not. Five follow-ups do most of the work:

  1. Ask for the last time. “Tell me about the last one” gets a real case instead of a general impression.
  2. Ask for a threshold. “Fast” becomes “a first reply within the working hour, for orders that shipped”.
  3. Ask for a name. “The data team” becomes the person who can grant read access.
  4. Ask for the exception. “What happens when the order is split across two trucks?”
  5. Ask what it replaces. If the new thing fails, what do people fall back on?

Six vague answers from the distributor, and the questions that fix them:

They sayYou ask
“Answer order emails”“Which kinds? Show me the last ten.”
“Use our data”“Which system is right when they disagree?”
“It should be accurate”“Which wrong answer costs you most?”
“Real time”“How old can the status be before it hurts?”
“IT will be fine with it”“Who in IT signs off? Can we meet them?”
“Everyone will use it”“Who uses it first, on which day?”

And one follow-up played out:

VP: “It has to be accurate.”

You: “Which wrong answer would hurt you most?”

VP: “Telling a contractor it shipped when it didn’t. They send a crew to the site.”

You: “Then for version one, the draft only says ‘shipped’ when there’s a carrier tracking number, and anything without one goes to a rep. Would that work for your team?”

That last line turns a feeling into a rule you can build and test. That is one layer peeled back, and it is the difference between a list of questions and discovery.

Close the call by playing it back

In the last minutes, read back what you heard and ask them to correct it:

“Here’s what I heard. Version one drafts replies to order-status emails for orders that have a tracking number, and routes the rest to the warehouse queue. It reads live status from the ERP, not the warehouse copy. Maria owns ERP access, and IT security needs a data flow diagram before go-live. Success in two weeks means Dana, your service lead, reviews a week of drafts for tracked orders and signs off that they can go out without edits. What did I get wrong?”

Send the same summary in writing that day. A wrong assumption caught in that email costs a reply; caught in week four, a rebuild. What goes in that written summary is scoping; how to scope an AI project for a customer covers it.

Mistakes that waste the first meeting

  • Pitching a solution in the first minutes. Once you name a tool, the customer answers questions about the tool.
  • Asking only technical questions. The decision process can stop a project as surely as the schema can.
  • Accepting “we have the data” without seeing a sample.
  • Leaving without a named owner for each system and a next step with a date.

Who owns discovery in FDE postings

Postings split this work differently, so read the one you are applying for. As of September 2026, OpenAI’s Forward Deployed Engineer posting in San Francisco says the hire will “own discovery, technical scoping, system design, build, and production rollout”. Source 4Forward Deployed Engineer (FDE) - SFPublisherOpenAI (Ashby)Source typecompany job posting Ramp’s Software Engineer, Forward Deployed AI Solutions posting, read the same month, says the engineer co-leads customer engagements with an AI Solutions Strategist and owns technical discovery. Source 5Software Engineer, Forward Deployed AI Solutions @ RampPublisherRamp (Ashby job board)Source typecompany job posting Notion’s Forward Deployed Engineer, India posting describes a migration-focused, initially internal role that partners with regional Forward Deployed Engineers, who own customer discovery, solution architecture and final customer validation. Source 6Forward Deployed Engineer, India @ NotionPublisherNotion (Ashby job board)Source typecompany job posting So prepare both ways: to run discovery yourself, and to build on someone else’s notes.

Using the list in a client or decomposition round

Some interviews test this directly. First Round Review reported, in February 2026, that Shilpa Balaji, a former FDE recruitment lead at Palantir, said Palantir’s FDE interviews included an insider-trading scenario in which candidates were asked what data they would need, what questions they would ask the customer and what they would look for, so interviewers could assess business and technical reasoning. Source 7So You Want to Hire a Forward Deployed EngineerPublisherFirst Round ReviewSource typenews report

In an interview you don’t have a full meeting, so compress. Our method, not an interviewer’s rubric:

The discovery list, compressed for an interview

  • Outcome: “What changes for the business when this works, and how would we measure it?”
  • Users: “Who uses it first, and what do they do today?”
  • Data: “Where does the data live, who owns it and how fresh is it?”
  • Systems: “What must it connect to, and how do users sign in?”
  • Constraints: “What must security approve, and is there a hard date?”
  • Decision: “Who signs off, and what do you need to see first?”
  • After each answer, say what it changes in the design.
  • Close with a playback and a first version.

Open with something like this:

“Before I suggest anything, I’d like ten minutes on six things: what success looks like, who uses this, what data you have, what it connects to, what could block it, and who signs off. I’ll tell you as I go what each answer changes in the design.”

Three habits carry the round:

If the round is a role-play with the interviewer as your customer, the customer role-play interview covers the moves when they are annoyed, vague or wrong. For practice with written prompts, try your first week with a vague problem and an urgent request that was not urgent.

In the free practice case, a city wants building permits to take weeks instead of months, and the mayor has already promised an AI review tool. The AI customer reveals what the brief leaves out only when you ask. The run lasts ten minutes and ends with a score that quotes your own words. Try the six groups on it now: run the free practice case. It’s free with a sign-in.

GlossaryForward deployed engineerA software engineer who builds and ships production systems inside a customer’s problem and environment, accountable to that customer’s outcome.More on Forward deployed engineer

Questions people ask

What questions should an engineer ask on a discovery call?

Ask about the outcome the customer needs, who will use the result and how they work today, what data exists and who owns it, which systems it must connect to, the security and timing constraints, and who decides and signs off.

Who runs discovery in a forward deployed engineer role?

It depends on the employer. As of September 2026, OpenAI’s FDE postings say FDEs own or lead discovery and scoping, and Notion’s posting for an FDE in India says regional FDEs own customer discovery.Source 4Forward Deployed Engineer (FDE) - SFPublisherOpenAI (Ashby)Source typecompany job postingSource 6Forward Deployed Engineer, India @ NotionPublisherNotion (Ashby job board)Source typecompany job postingSource 8Forward Deployed Engineer (FDE), Financial Services- NYCPublisherOpenAI (Ashby)Source typecompany job posting

What if the customer’s data does not match what they described?

Expect it, and plan the call around it. Ask to see ten real records and the screen where people look them up before you commit to a design, and name the gap in your written summary the same day.

Keep reading

Guides

Lessons

Questions

More in Interview rounds