By FDE Interview Prep, a SourceStrongAI company

In this post11 sections
  1. Two reports of the same feedback
  2. What employers say about the technical bar
  3. Which round cost you: a diagnostic
  4. When the gap is coding speed and correctness
  5. When the gap is depth in design and domain knowledge
  6. When the gap is how you showed your technical decisions
  7. A drill plan to close the gap
  8. Asking for feedback and reapplying
  9. Questions people ask
  10. Keep reading
  11. More from the blog

“Great communicator, not technical enough.” You made it through an loop, the customer half felt like your strongest ground, and this is the line the recruiter read out. The plain answer: that feedback names a gap in one or two rounds, not a verdict on you. Find the round that produced it, work out which of three gaps it was (coding, depth, or how you showed your decisions), and drill that one skill. It is worth the work: Ramp says its FDE candidates must pass the software engineering loop, and Baseten says every FDE candidate must pass its standard technical bar. Source 1What is a Forward Deployed Engineer? (FDE Explained) feat. Leo Mehr of Ramp (YouTube auto-generated English captions)PublisherdearCC (Clara Shih), YouTubeSource typerecorded talk or interviewSource 2Forward deployed engineering on the frontier of AIPublisherBasetenSource typecompany blog This post is one narrow piece of the FDE interview guide, which covers every round of the loop.

Two reports of the same feedback

One candidate with 10 years of experience reported on Blind, in May 2026, that their Google FDE GenAI loop in India had a LeetCode medium-hard coding round, whose feedback was a level call (“hire for L4, not L5”), and ended in rejection. Source 3Google Rejected for FDE. Need immediate referralPublisherBlind (teamblind.com)Source typecandidate report on Blind The same Blind poster wrote that their second round, a separate round they called RRK and described as deeply technical, came back as “not technical enough to face customers or something like that”. Source 3Google Rejected for FDE. Need immediate referralPublisherBlind (teamblind.com)Source typecandidate report on Blind

One candidate reported on Reddit, in June 2026, that while looking for roles mostly in the FDE space they reached 4 final rounds, and all four gave the same feedback: a great communicator, but technical skills not what the companies were looking for. Source 4Good communicator, but technical skills not up to par; pivot options? (post by u/calculusbitch99)PublisherReddit r/cscareerquestionsSource typecandidate report on Reddit That poster, one candidate with 3 years as a software engineer, wrote that in some cases it seemed to be a mismatch with the specific domains the companies wanted. Source 4Good communicator, but technical skills not up to par; pivot options? (post by u/calculusbitch99)PublisherReddit r/cscareerquestionsSource typecandidate report on Reddit The poster did not name the companies or say which roles the final rounds were for.

Two reports say nothing about how often this happens, but they show one label covering three problems:

  • A level problem. The Blind poster’s coding round came back as a level below the one they applied for.
  • A depth problem. The “not technical enough” line came from a different round from the coding one.
  • A domain problem. The Reddit poster suspected a mismatch with each company’s field.

Algorithm drills will not repair a domain mismatch.

What employers say about the technical bar

Not every FDE track is the same, though. Nabeel Qureshi, who spent nearly eight years as a Palantir FDE, said on Lenny’s Podcast, YouTube, in May 2025, that Palantir had two types of FDE: one passed a software engineering interview; the other’s technical interview was more about whether the candidate could reason about data. Source 8How Palantir built the ultimate founder factory | Nabeel S. Qureshi (YouTube uploaded en-US captions)PublisherLenny's Podcast, YouTubeSource typerecorded talk or interview Check which kind of loop you sat before you pick a drill.

Our reading of the word “double”: being far above the customer bar does not lower the technical one. Plan to clear both. The double bar lesson takes each half apart, and if someone has told you FDE is “SWE-lite”, is FDE a step down from software engineering? looks at the evidence on the bar.

A counterweight: Leo Mehr wrote on Ramp’s engineering blog, in August 2025, that candidates who performed just okay in coding interviews, mixed or soft yeses, have turned out to be incredible FDEs once they joined. Source 9Forward Deployed Engineering (Leo Mehr, Director, Engineering)PublisherRamp Builders (engineering blog)Source typecompany blog That is no promise a soft round passes, but it is a reason to treat the feedback as a skill to build, not a ceiling.

Which round cost you: a diagnostic

This diagnostic is ours. While the loop is fresh, give each round a line and answer:

  1. What was the deepest follow-up you were asked? Write the exact question, not a summary of it.
  2. What did you answer it with? A specific (a number you measured, a named tradeoff, a failure mode) or a summary (“we made it scalable”)?
  3. In a coding round, did you finish? Working code, without a hint, with at least one test, and no bug the interviewer found before you did.
  4. Where did the interviewer move on? In our reading, the spot where the questions stopped may be where they had their answer.

Then match what you wrote:

What you noticeLikely gap
A hint, unfinished code, or a bug they foundCoding speed and correctness
A level call, such as “L4, not L5”Coding depth for the level
You ran dry two follow-ups deepDesign or project depth
Questions about a stack or field you had not usedDomain match
You knew it, but gave the business versionHow you showed your decisions

A worked example, fictional. A candidate had four rounds: coding, system design, a customer case and a project deep dive. The customer case went well. In coding, they finished, tested it, and answered the one question about memory. In design, the follow-up “what happens when the customer’s identity provider is down?” got “we’d add retries”. In the deep dive, “why a queue there?” got “it’s more reliable”. The pattern is not coding. It is the last row of the table, plus some design depth: every hard question got a summary instead of a mechanism.

A stronger answer to the identity provider question: “Sessions already issued keep working until they expire, so existing users are fine. New logins fail. I’d show a clear ‘your company’s sign-in is unavailable’ page instead of our generic error, alert on the spike in failed logins, and not retry in a tight loop, because that hammers their IdP when it comes back. The open question for the customer is whether they want a break-glass admin login.” It names a mechanism, what the user sees, a metric and a tradeoff.

When the gap is coding speed and correctness

Palantir’s coding-interview guide says a core facet of a good coding interview is translating a conceptual solution into working code, and it tells candidates to think about edge cases and how their code could break. Source 10Writing Good CodePublisherPalantirSource typecompany hiring page Drill exactly that: idea to correct code on a clock, with the breakages named before the interviewer names them.

Start with what FDE coding rounds test, a free lesson on the four kinds of coding round. If your loop had algorithm problems, whether FDE interviews have LeetCode goes company by company through what employers publish and candidates report.

Here is what “naming the breakages” sounds like on a small problem: dedupe customer rows by email.

def dedupe(rows):
    seen, out = set(), []
    for r in rows:
        email = r.get("email") or ""
        key = email.strip().lower()
        # no email: keep, never merge
        if not key:
            out.append(r)
            continue
        if key not in seen:
            seen.add(key)
            out.append(r)
    return out

The words around the code are what a “not technical enough” answer leaves out:

  • “I’m normalizing case and whitespace, because a CRM export can have Ana@x.com and ana@x.com for the same person.”
  • “Strictly, the part before the @ can be case-sensitive under the email standard. I’m lower-casing it because treating it that way is the practical norm, and I’d confirm with the customer.”
  • “This keeps the first row and drops the rest. If later rows carry fields the first lacks, I’d merge instead, and I’d ask which source wins.”
  • “Rows with no email I keep rather than merge. Merging on an empty key would collapse every unknown contact into one row.”
  • “It’s one pass, linear time, and the set holds one entry per distinct email.”
  • “First test: two rows that differ only by case and a trailing space should give one row.”

RFC 5321, section 2.4 says the local part must be treated as case-sensitive, so lower-casing it is a choice you say out loud.

Common mistakes in this gap, and the fix for each:

  • Coding before the edge cases. Name the inputs that break it, then write.
  • Testing only the happy path. Test one value you can check by hand, then one bad input.
  • Stalling in silence. Say the brute force out loud and ask whether it is enough before you optimize.
  • Only practicing blank files. Palantir defines one interviewed competency as working within existing systems and codebases, and says developers spend far more time debugging, modifying and extending existing code than writing new code. Source 11Working Inside Existing SystemsPublisherPalantirSource typecompany hiring page Practice on someone else’s code too.

Good problems for this gap, all free: the token bucket rate limiter, the messy CSV parser and refactoring a long function so you can test it.

When the gap is depth in design and domain knowledge

In our reading, this is the gap that feedback like “not technical enough to face customers” points at. A customer’s engineers ask the second and third question, so the interviewer will too.

The two-levels-down drill. Take any design you have drawn, in practice or at work. For each box, write three lines:

  1. What it does.
  2. How it fails, and what the customer sees when it does.
  3. What you would measure to know it is healthy.

A worked box, the upload queue:

  • Does: buffers uploads so the API can return at once.
  • Fails: when workers fall behind or a poison file loops; the customer sees “processing” that never finishes.
  • Measure: queue depth, the age of the oldest message, and the dead-letter count.

If you cannot write line two for a box, an interviewer will find that edge. Fill it in first.

Enterprise design has its own questions: identity, tenancy, , a customer’s network you do not control. Enterprise system design is not ‘design a social network’ is a free lesson on what changes. Then practice on the SSO design question and the bulk import design question, writing line two for each follow-up you expect.

Domain match. If the questions were about a stack or field you had not used, the fix is narrow and fast:

  • List every technical term in the posting: the cloud, the data systems, the AI stack, the regulated field.
  • For each term you cannot explain from use, build one small thing with it.
  • Apply where your list is short. The Reddit poster suspected the same of some of their final rounds.

When the gap is how you showed your technical decisions

A strong communicator can fall into this without noticing: explaining things to an engineer as you would to an executive.

Compare two answers to “Why did you put a queue between the API and the workers?”

  • The business version: “It made the system more reliable and let us scale when traffic grew.”
  • The engineer’s version: “Uploads arrived in bursts after the nightly export, and the workers took a few seconds per file. Without the queue the API timed out. With it, the API returns at once and the workers drain at their own pace. The cost is that a failure is now asynchronous, so I added a and a status endpoint.”

Only the second shows a decision. Use this shape for any technical choice:

  1. The constraint. What was true that forced a choice.
  2. The decision. What you picked, said as “I”, if it was yours.
  3. The alternative. What you did not pick, and why.
  4. The cost. What your choice made worse, and how you handled it.

Three habits that sound “not technical” in the room, and what to say instead:

  • “We” for everything. Say which parts you built. The question on which decisions were yours drills exactly this.
  • No numbers. Replace “fast” with the number you measured, or say how you would measure it.
  • Deferring down. “The infra team handled that” ends the thread. Try: “The infra team owned it. My understanding is it worked like this, and here is where I’d check.”

The project deep dive question is the best place to practice all four steps: you pick the material.

A drill plan to close the gap

This plan is ours. Drill the gap the diagnostic found, not the round you enjoy. If your next onsite is already booked, the post on spending the days before an onsite splits a short week; this plan is for the longer stretch after a rejection.

First, a baseline. Record one cold attempt at your gap: a timed coding problem, a design walked two levels down, or a deep dive said out loud. This is what you will compare against.

Then, one gap per session. Each session has three parts:

  1. One timed rep in the gap. Set the timer to the round length your recruiter gave you.
  2. One recorded explanation. Explain your reasoning out loud, as if to the interviewer, and record it.
  3. One review. Play it back and count the specifics: numbers, tradeoffs, failure modes. If there are none, redo the explanation, not the problem.

Keep the other bar warm. Drilling only code lets the customer side go stale. Now and then, run the free practice case to keep your scoping sharp.

Retest before you reapply. Repeat the baseline with a new problem of the same kind, and compare the recordings.

Signs the gap is closing

  • You say the edge cases before you write code
  • Every design box has a failure mode and a metric
  • Your deep dive answers “why that?” with a constraint
  • Your recordings say “I” for the decisions that were yours
  • You finish a timed problem with a test, without a hint

Want model answers to score your recordings against? Pro opens the model answer on every question marked Pro and lessons like the double bar. Pro starts with a 7-day free trial.

Asking for feedback and reapplying

Ask, but plan not to get much. Anthropic’s careers FAQ says it is not able to provide feedback on resumes or interviews. Source 12Careers \ AnthropicPublisherAnthropicSource typecompany hiring page So the diagnostic works from what you were asked, not what they tell you.

If the recruiter will talk, keep it short:

“Thank you for letting me know. So I can work on the right thing, could you tell me which round the concern came from, and whether it was about the level or the fit for this role?”

If the feedback was a level call, like the Blind poster’s, add a second question: “Is a role at the level below open, or worth applying to?”

When you reapply, ask the recruiter when you may. Bring new evidence, not the same story told better: a project shipped since, a design you can take two levels down, a deep dive with numbers. Say it plainly: “Last time the feedback pointed at depth in design. Since then I have done this, and I’d like to show you.”

Pick the question that matches your gap and answer it out loud today: the token bucket for coding, the SSO design for depth, or which decisions were yours for how you show them.

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 engineerGlossaryData residencyA requirement that data, including logs and backups, be stored and processed in a specific region.More on Data residencyGlossaryDead-letter queueA holding place for messages that failed processing too many times, kept for inspection and replay.More on Dead-letter queue

Questions people ask

What does ‘not technical enough’ mean after an FDE interview?

Some employers say they cannot give interview feedback at all; Anthropic’s careers FAQ is one. So read the line as a gap in a specific round, not a verdict on you. Work out which round asked the deepest technical questions, and start there.Source 12Careers \ AnthropicPublisherAnthropicSource typecompany hiring page

Do FDE candidates have to pass the same technical bar as software engineers?

Some employers say so. Ramp’s Director of Engineering Leo Mehr said in June 2026 that FDE candidates at Ramp must go through and pass the software engineering interview loop, and Baseten’s FDE lead writes that every FDE candidate must pass Baseten’s standard technical interview bar.Source 1What is a Forward Deployed Engineer? (FDE Explained) feat. Leo Mehr of Ramp (YouTube auto-generated English captions)PublisherdearCC (Clara Shih), YouTubeSource typerecorded talk or interviewSource 2Forward deployed engineering on the frontier of AIPublisherBasetenSource typecompany blog

Can I ask an employer for detailed interview feedback?

You can ask, but some employers say they cannot give it. Anthropic’s careers FAQ says it is not able to provide feedback on resumes or interviews, so plan to diagnose the gap yourself from what each round asked.Source 12Careers \ AnthropicPublisherAnthropicSource typecompany hiring page

Keep reading

Guides

Lessons

Questions

More in Preparation