TL;DR: This is a flight-risk filter. Answer with evidence you already chose customer proximity when you didn't have to, name the downside you've accepted eyes-open, and never frame the role as a stepping stone back to pure SWE.
How to approach it
The answer that fails is the one everyone gives: "I love technology and I love people." It is a preference, not evidence, and the interviewer has heard it from the last three hires who transferred back to product engineering within a year. Understand what's actually being screened: FDE/SA teams have a well-known attrition pattern, strong engineers join, discover that half the job is meetings, travel, and customer politics, and transfer back to product engineering within a year. The interviewer has watched this happen. So "I love technology AND people" fails, because everyone says it and it predicts nothing. What passes is evidence: times you already chose customer proximity when you didn't have to, and a clear-eyed account of the job's downsides that you've accepted anyway.
A strong answer
Three moves: evidence, eyes-open realism, and why this beats the alternative for you.
"Three pieces of evidence rather than a speech. First, in my last role I volunteered for every customer escalation, I was the engineer who got pulled into the call when the integration broke, and I noticed I came back from those calls energized while my teammates came back drained. Second, my best shipped work started with something a user said in a meeting, not something in a ticket; I'm measurably better when I can see the person whose week I'm fixing. Third, I've already done the unglamorous parts, I've sat in a customer's conference room until 9pm reconciling their data, and I went back the next week voluntarily.
What I'd miss from pure engineering is long uninterrupted build time, and I know FDE work fragments that. I'm trading depth of codebase for depth of problem, I'd rather own 'did the customer's fraud losses go down' than 'is this service at four nines.' The feedback loop of watching someone use what I built last Tuesday is the thing I can't get in a product org.
And on quitting: the failure mode is people who didn't know what they signed up for. I do, travel, ambiguity, being the face of every bug in the platform. I'm choosing it because the alternative bored me."
| Reason people give | Why it fails the follow-up |
|---|---|
| "I like working with people" | Describes a preference, not the job. The job is engineering under ambiguity |
| "I want more impact" | Every role claims this. Impact at what, measured how |
| "I get bored building the same thing" | Reads as a tolerance problem, not a pull |
| "I want to be closer to the customer" | Closer than what, and what did you do about it in your last role |
| Evidence you already did this unpaid | The only one that survives: you talked to users, you owned a deployment, you went on-site |
The convince-me-you-will-not-quit half is answered by naming the parts you know are unglamorous, travel, integration work, other people's legacy systems, and saying why you still want it.
If your title has never had "customer" in it, the evidence still exists; it is just filed under different names. Internal customers count fully: the analyst team you sat with for a week before building their tool, the support engineers whose top ticket category you eliminated after reading a hundred tickets yourself, the time you rewrote a runbook because you watched someone struggle through the old one at 2am. On-call counts, if you engaged with the people affected rather than just the pager. Open-source issue triage counts, because reproducing a stranger's bug from a half-legible report is customer empathy in its purest form. What you are looking for in your own history is any moment you voluntarily crossed the boundary from "my code" to "their problem" when staying on your side was allowed. Two honest, small stories of that shape beat one grand vague claim, and the interviewer can tell the difference in the follow-ups, because real stories survive "what did they say when you showed them?" and invented ones do not.
What interviewers probe next
- "Tell me about a customer interaction that went badly." They want proof you've felt the friction, not just the upside.
- "What happens when the customer is wrong and won't budge?", bridge to trusted-advisor behavior, not capitulation or stubbornness.
- "Which part of this job do you expect to like least?" Have a real answer (status reporting, repeated travel to the same site) and a coping mechanism.
- "Where do you want to be in three years?" Safe ground: deeper at the intersection, staff FDE, deployment lead, not "back to core engineering."
What to actually do
Before the loop, write down two moments you crossed from "my code" to "their problem" when staying on your side was allowed, with what the person said when you showed them. Rehearse the three-year question until the answer lands on the intersection, staff FDE or deployment lead, without hesitation. Pick the part of the job you expect to like least and decide, in advance, how you will cope with it. Then say all three in the room without being asked.
Common mistakes
- Zero evidence. If you can't name a single time you voluntarily faced a customer, the interviewer concludes you're guessing about your own preferences.
- Describing FDE work as a stepping stone to product engineering or PM, that's a confession of flight risk.
- Pretending there are no downsides. Calibrated honesty about the grind is itself a scored signal.
- Trashing pure engineering ("I got bored of coding"), the job is still 60% engineering, and they need you to love that part too.