The candidate across the table has a beautiful résumé. Big logos, distributed systems, a conference talk you've heard of. You ask about consistency models. He is magnificent. You hire him. Four months later he's built an elegant event-sourced platform for a client who needed a form that emails somebody.

FDE interviews fail when they test for the wrong job. The job is not "senior engineer, but on-site." It's a strange hybrid: product judgment, scoping speed, client empathy, and enough engineering depth to ship alone on a Tuesday.

The best forward deployed engineer interview questions probe three things: how fast a candidate scopes, how they treat unhappy users, and whether they reach for boring technology under pressure. Here are fifteen questions across those three areas, with the answers that signal a builder and the ones that signal a beautiful résumé.

Why forward deployed engineer interview questions aren't trivia questions

Quizzing candidates on CAP theorem filters for people who are good at interviews. The client with the broken receiving workflow does not care about your hire's grasp of consensus protocols. They care that labels print at the dock door. Design the interview around that gap.

You still need technical signal. You just get it better from stories and work samples than from recitation. Ask about the messiest thing they've shipped, not the most impressive.

There's a second reason trivia fails here, and it's structural. FDEs work alone at the edge of your organization, in rooms where nobody can check their technical claims. The interview has to test what they'll do unsupervised with ambiguous instructions and a frustrated warehouse manager. Textbook questions test what they did in a classroom, once, with a syllabus.

Scoping questions (1–5)

These five test the muscle that matters most: shrinking a problem until it fits in a week. Listen for specifics, dates, user names, and the exact thing they cut.

  1. "Walk me through something you shipped in a week or less." Good: specific, small, mentions what they cut. Red flag: nothing that small exists.
  2. "Here's a feature from our world — what would you cut to ship it Friday?" Good: cuts ruthlessly and keeps the user's core win. Red flag: "I'd need a longer discovery phase."
  3. "Tell me about a time the spec was wrong. What did you do?" Good: talked to a user and changed the plan. Red flag: blamed the spec and built it anyway.
  4. "How do you decide when a script is enough and when something needs to be a real app?" Good: has a threshold and mentions maintenance. Red flag: always builds the app, or never does.
  5. "Describe a project you killed or shrank." Good: names one, with the math. Red flag: has never killed anything, which means they've shipped monuments.

The pattern to listen for: candidates who mention users inside scoping answers. Scoping is a user skill disguised as an engineering skill.

Client empathy questions (6–10)

Empathy questions separate people who build for users from people who build at them.

  1. "Tell me about a user who hated your first version." Good: a specific person, changed behavior, slightly sheepish tone. Red flag: "the users didn't get it."
  2. "How do you gather requirements from someone who says 'just make it like the old system but better'?" Good: watches them work, asks about their worst day. Red flag: sends a questionnaire.
  3. "Describe a time you pushed back on a stakeholder's request." Good: pushed back with a smaller alternative and shipped it. Red flag: never pushes back, or treats pushback as war.
  4. "What's the least technical thing you've done that made a project succeed?" Good: a training session, a renamed button, an evening with the night shift. Red flag: can't think of one.
  5. "How do you hand off something you built?" Good: docs, a walkthrough, a named owner. Red flag: "it's self-explanatory."

Notice the theme. Good answers have other people in them. Bad answers contain only the candidate and their brilliance.

Technical judgment questions (11–15)

Finally, depth — but aimed at judgment rather than trivia.

  1. "What's the most boring technology you love, and why?" Good: Postgres, cron, a queue, with war stories attached. Red flag: contempt for boring tools.
  2. "What would you refuse to build for a client even if they insisted?" Good: names maintenance or ethical traps and explains calmly. Red flag: nothing; they'd build anything for a check.
  3. "A client's production system is down, it's not your code, you have read-only access and thirty minutes. Walk me through it." Good: narrows hypotheses, checks boring causes first, communicates while debugging. Red flag: opens by proposing a rewrite.
  4. "Tell me about debugging in someone else's messy environment." Good: respect for the mess, small reversible steps. Red flag: "the codebase was garbage" as the entire answer.
  5. "How do you keep a script you wrote alive after you leave?" Good: logging, alerts, a README, an owner. Red flag: hasn't thought about after.

Question 13 is the single best proxy for the job. An FDE's week is exactly that: someone else's system, partial access, real clock.

Running the interview itself

Format beats question lists. Do a work sample: a messy CSV, a fake API, ninety minutes, and watch how they scope before they code. Add a thirty-minute roleplay where you play a slightly unreasonable stakeholder and say "the ops manager wants X, scope it with me." Clients occasionally are unreasonable, and the roleplay shows you the Tuesday version of the candidate. Score both exercises on what they cut and who they asked about, not on how much code appeared.

Check references with business stakeholders, not just engineers. Ask the ops manager from their last project one question: when this person left, what broke? The pause before the answer is the answer.

If you're building the full hiring loop, pair these questions with a job description that attracts builders instead of résumé collectors, calibrate the offer against current FDE salary ranges, and if you're on the other side of the table, the candidate's-eye view is in what the Palantir FDE interview actually looks like. Then go ask question 6 and listen for a name.