By FDE Interview Prep, a SourceStrongAI company

In this post10 sections
  1. Why ‘we’ becomes a problem at the follow-up
  2. What do interviewers actually ask about ownership?
  3. The ownership audit, line by line
  4. Before and after: one story rewritten
  5. Keep the team in the story without hiding in it
  6. The follow-ups that expose a borrowed story
  7. The audit checklist
  8. Questions people ask
  9. Keep reading
  10. More from the blog

Your best story is a team story. You tell it well, the interviewer nods, and then asks “what did you decide?”, and you realize every sentence you prepared starts with “we”. The short answer to the “I vs we” question is: say “we” for what the team did and “I” for what you decided, built or changed, and make your part specific enough to survive a follow-up. This post is one narrow piece of the FDE interview guide: a line-by-line audit that turns a team story into an answer about you, one story rewritten before and after, and the follow-up questions that expose a story you did not own.

Why ‘we’ becomes a problem at the follow-up

“We” is not the mistake. Most real work is team work, and pretending otherwise is worse. The problem is what “we” hides. When every sentence has the team as its subject, the interviewer cannot tell which choices were yours, so they ask. That follow-up is where prepared answers fall apart.

Here is the pattern. You say “we moved to incremental loads.” The interviewer asks why incremental and not a second full pass. If you made that call, you answer in one breath: what you compared, what you rejected, what convinced your lead. If you did not, you stall, or you guess at reasons someone else had. The pronoun did not cost you anything. The missing decision did.

So the fix is not a find-and-replace from “we” to “I”. It is knowing, sentence by sentence, which parts of the story were yours, and having the reasoning ready for each.

What do interviewers actually ask about ownership?

Start with what people who hire have said in public.

Leo Mehr, Director of Engineering at Ramp, said on a podcast published in July 2026 that he assesses drive and ownership by asking candidates about the decisions they made, what they were responsible for and how much responsibility they took on. Source 1Leo Mehr - Ramp's $44B Bet on Services (YouTube auto-generated English captions)PublisherBasil Chatha, YouTubeSource typerecorded talk or interview He was describing how he assesses candidates, not a particular interview round. In an August 2025 post on Ramp’s engineering blog, he wrote that what matters most when recruiting FDEs is drive, communication and “the will to solve customer problems end-to-end”. Source 2Forward Deployed Engineering (Leo Mehr, Director, Engineering)PublisherRamp Builders (engineering blog)Source typecompany blog A story told entirely in “we” makes that hard to see.

Palantir’s careers page says its onsite interviewers ask how you have executed, challenged yourself, motivated others and made judgments, and where you have failed. Source 3Getting Hired - Palantir CareersPublisherPalantir TechnologiesSource typecompany hiring page Judgments and failures are personal. “We made a judgment” is a strange sentence.

Sierra’s Natalie Meurer said, in her AI Engineer World’s Fair 2026 talk, that across the different versions of the role, every forward deployed engineer is accountable to the customer. Source 4The Dirty Secret of Forward Deployed Engineering (Natalie Meurer, Head of Agent Engineering, Sierra; AI Engineer World's Fair 2026)PublisherAI EngineerSource typerecorded talk or interview Accountability is the job, so a story about customer work should show what you were accountable for.

Now the claim you may have read elsewhere. One prep guide, from Aced (formerly Exponent), asserts that FDE hiring managers screen for “I did” rather than “we did” language, and it cites no source for it. Source 5Forward Deployed Engineer Interview: The Definitive 2026 Guide (FDE)PublisherAced (formerly Exponent)Source typeinterview prep site None of the employer statements we collected mentions pronouns. What hiring leaders describe is asking which decisions were yours. So don’t prepare for a pronoun count. Prepare for the question behind it: what were you responsible for, and what did you decide?

If you want the wider picture of what hiring leaders say they look for, the lesson what hiring leaders say they look for collects those statements, and the double bar covers being technical enough while being trusted in front of a customer.

The ownership audit, line by line

The ownership audit is our method for this. It is a pass over a story you plan to tell, so that every decision in it has a named owner. It is not something interviewers publish or score by.

  1. Write the story as you would say it, one sentence per line. Don’t polish yet. Say it out loud first if writing feels slow.
  2. Tag every line with one of four labels:
TagMeansSay it as
CContextPlain fact
TThe team did it“We” or a role
MYou decided or did it“I”
?You can’t tellFix it
  1. Resolve every “?” line. Ask who actually did it. If it was you, rewrite it with “I”. If it was someone else, name them by role: “our tech lead”, “the customer’s data engineer”. Passive lines (“the decision was made to roll back”, “it was decided”) always get a “?”, because they hide the owner.
  2. Turn every M line into a decision. A decision has four parts: what you chose, the alternative you rejected, why, and how you knew it worked. “I built the dashboard” is an action. “I built the dashboard on the raw event table instead of the daily summary, because the summary dropped late events” is a decision.
  3. Check the balance. If the M column is nearly empty, the fix is a different story, not better pronouns. If every line is M, you are probably claiming calls that belonged to someone else, and the first follow-up will find it.
  4. Write the follow-up each M line invites, and answer it out loud. The section below lists the ones to expect.

Before and after: one story rewritten

The story below is fiction. The employer and the customer are invented, to show the audit working on one answer.

The question is “Tell me about a time you fixed a problem after launch.”

Before, as first told, with each line tagged:

We were brought in to connect a regional insurer’s policy system to our analytics platform. (C)

We built a nightly sync, and after go-live we noticed records were going missing. (T, ?)

We looked into it and realized the export was skipping updates made while the job ran. (?)

We decided to move to incremental loads and added some checks. (?)

The claims team was really happy with the result. (?)

The last line isn’t context. It’s an outcome with no evidence, so the audit flags it too. Almost every line has “we” as its subject, and no line has an M. The interviewer’s next question is going to be “what was your part?”, and the story has no answer ready.

Now the audit. The writer asks who noticed the missing records (the customer’s claims lead, who told them), who found the cause (they did), who chose the fix (they proposed it, and the tech lead approved it) and who built the checks (they did). They also admit what they would change.

After:

I was the deployed engineer on a small team connecting a regional insurer’s policy system to our analytics platform. (C)

The team built the nightly sync. (T)

I owned the claims tables. (M)

Shortly after go-live, the claims lead told me her morning dashboard was missing a handful of claims. (C)

I compared row counts table by table and found the export paged through the table with OFFSET, ordered by last-modified time, so when a record was updated mid-run, the rows behind it shifted between pages and some were skipped. (M)

Our tech lead’s first idea was to run the full export twice and merge the results. (T)

I proposed incremental loads keyed on the last-modified timestamp, with an overlap window so late updates were picked up, and upserts on the claim ID so the overlap couldn’t create duplicates. (M)

I argued against a second full pass because the export already ran for most of the night, so it had no room to grow. (M)

He agreed once I showed him the overlap handled the edge case. (T)

I also wrote a reconciliation check that compares counts per table every morning and alerts the claims lead and me when they differ. (M)

It caught a second upstream problem a few weeks later, before anyone saw it on a dashboard. (M)

What I’d change: I’d build that check before go-live, not after. (M)

What changed:

  • The team is still there. The tech lead has a real idea and approves the fix. The claims lead spots the problem. Crediting them makes your part more believable.
  • Every “I” line is a decision or an action with a reason. Incremental loads over a second full pass, and why. An overlap window, and the duplicate problem it creates, and how the upsert handles it.
  • The ending is a lesson, not applause. “The claims team was really happy” tells the interviewer nothing. A thing you would do differently shows judgment.

The technical detail matters because it is where a follow-up goes next. If you say “overlap window”, expect “how big, and what happens to a record updated twice in it?” You should know: the upsert is keyed on the claim ID and only overwrites when the incoming last-modified time is newer, so a record loaded twice ends up as one row with its latest version, not two rows. A plain upsert would keep whichever copy arrived last, so a retried older copy could overwrite newer data.

Then expect the next one: “And deletes?” An incremental load keyed on last-modified never sees a row that was hard-deleted at the source. The honest answer is that the morning reconciliation count would show the gap, and you would say how you handled it: a soft-delete flag from the source, or a periodic full comparison of IDs.

Keep the team in the story without hiding in it

The opposite failure is real too: an answer where you did everything. It sounds rehearsed, and it breaks the moment someone asks what your manager thought. These phrasings keep the credit accurate:

  • Credit by role, then say your part. “Our tech lead chose the warehouse. I designed the tables for the claims data.”
  • Split shared decisions. “That was the product lead’s call. I brought her the numbers from the shadow run.”
  • Say what was fixed before you arrived. “The deadline and the stack were set before I joined.” Naming what you didn’t control makes the rest believable.
  • Own the misses in the first person. “I didn’t test the other regions’ exports” is stronger than “some regions weren’t covered”. The same habit works with customers; see ownership language.
  • Use “we” for outcomes you shared. “We went live on schedule” is accurate and fine.

Three kinds of “we” in a deployment story

FDE stories have a problem most behavioral advice misses. “We” can mean three different groups, and the interviewer can’t tell which:

  • Your company’s team. “We shipped the connector” could mean you, your lead or the whole deployment team.
  • The customer’s staff. “We decided to keep the old system running” might have been their IT director’s call, not yours.
  • Both together. “We agreed to delay the launch” hides who proposed it, who had the authority, and who carried the risk.

Natalie Meurer’s point that every forward deployed engineer is accountable to the customer Source 4The Dirty Secret of Forward Deployed Engineering (Natalie Meurer, Head of Agent Engineering, Sierra; AI Engineer World's Fair 2026)PublisherAI EngineerSource typerecorded talk or interview is why the customer side of the story is exactly where a follow-up will probe. Name the group each time. For example:

  • Before: “We agreed to delay the launch.”
  • After: “The customer’s CIO chose to delay. I recommended it and brought her the failed-reconciliation counts.”

The after version shows the customer’s authority, your judgment and your evidence in two sentences.

The follow-ups that expose a borrowed story

A borrowed story is one you were near but did not drive: your lead’s decision, a teammate’s fix, a project you watched from the next desk. It passes the first telling. It fails the follow-ups, because they ask for things only the person who decided would know.

In a July 2025 Palantir video in which hiring managers spoke to software engineering candidates, one said they “don’t necessarily want to hear your sort of prepared statement of what you think we want to hear”, and asked candidates to “be real in the interview process”. Source 6From Code to Career: Meet Palantir's Hiring Managers (YouTube uploaded English captions)PublisherPalantir, YouTubeSource typerecorded talk or interview The audit is a good way to find out, before the interview, which of your stories are real in that sense.

Expect questions like these, and check each M line against them:

  • “What was the other option, and who wanted it?” A borrowed answer names no alternative. An owned one says who argued for what.
  • “What would have happened if you’d been out that week?” If the honest answer is “the same thing”, it wasn’t your decision.
  • “How did you know it worked?” Owned: the check, the count, the date you looked. Borrowed: “the customer was happy”.
  • “What did you get wrong?” Owned answers have a specific miss and what you changed. Palantir’s careers page says its onsite interviewers ask about failures. Source 3Getting Hired - Palantir CareersPublisherPalantir TechnologiesSource typecompany hiring page
  • “What would your manager say you owned?” If you would need to hope, rewrite the story until you don’t.
  • “Walk me through how that part worked.” Two levels down into your own work should feel easy. Two levels down into someone else’s is where a borrowed story ends.

Practice these on the question which decisions were yours alone?. Its framework sorts decisions into yours, shared and fixed, and its illustrative answer shows the split out loud. Then try a project you owned end to end and the customer outcome you’re proudest of, which ask for the same thing in different words.

The audit checklist

The ownership audit

  • The story is written one sentence per line.
  • Every line is tagged C, T, M or ?.
  • No “?” lines remain, and no passive line hides who decided.
  • Every M line names the choice, the alternative, the reason and the evidence.
  • Teammates appear by role, with their real part.
  • At least one M line is a miss, with what you changed after it.
  • You have said each follow-up answer out loud, not just read it.
  • The ending is a result you measured or a thing you would change, not “they were happy”.

Run it on the three stories you are most likely to tell. The audit often shows that the story you liked best has the thinnest M column, and a smaller project where you made a real call is the better one to lead with. For more on shaping the whole answer, see a STAR answer that survives an FDE loop, the project deep dive and a customer escalation story.

The same habit of naming your own call matters in customer rounds. The free practice case puts you in front of a simulated customer who answers your questions, and it will show whether you can say what you would decide and why.

When you have a clean story, run it through the behavioral questions: which decisions were yours alone? again with the rewritten version, which is free, then the cross-functional launch you drove, in Pro. Each question has a model answer and the follow-ups to expect.

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

Should I say ‘I’ or ‘we’ in a behavioral interview?

Both, accurately. Say ‘we’ for what the team did and ‘I’ for what you decided, built or changed, and make those parts specific. Ramp’s Director of Engineering, Leo Mehr, has said he asks candidates about the decisions they made and what they were responsible for.Source 1Leo Mehr - Ramp's $44B Bet on Services (YouTube auto-generated English captions)PublisherBasil Chatha, YouTubeSource typerecorded talk or interview

A prep site says FDE hiring managers screen for ‘I did’ over ‘we did’. Do they count how often I say ‘we’?

We can’t confirm it. No employer statement we found says so. One prep guide, from Aced (formerly Exponent), asserts that FDE hiring managers screen for ‘I did’ rather than ‘we did’ language, and it cites no source for it. What hiring leaders do describe is asking which decisions were yours.Source 5Forward Deployed Engineer Interview: The Definitive 2026 Guide (FDE)PublisherAced (formerly Exponent)Source typeinterview prep site

Is it arrogant to say ‘I’ about team work?

Not when the credit is accurate. Give the team its part, then say which decision was yours, what you weighed, and what you would change. Accurate credit is what holds up when the interviewer asks a follow-up.

Keep reading

Guides

Lessons

Questions

More in Interview rounds, page 3