The FDE round candidates underrate and Distyl weighs most

Picture yourself in the onsite loop. The interviewer changes tone and plays the customer’s head of operations: “Our compliance team has just blocked sending data to the model. Go-live is next week. What do you suggest?”

Many candidates fall back on one of two reflexes. The first pushes the work back to the customer: “You’ll need to get that approved on your side, and once it’s approved we’ll deploy straight away.” The second dives straight into architecture: mask the data, run the model in-house, add a filtering layer. Either can sink you, each for its own reason.

This article walks through a third way to answer: take ownership, but don’t rush to an answer. It is a skill you will need in every customer session once you are hired, not just to get through the interview.

The most underrated round carries the most weight

An analysis of Distyl AI’s FDE hiring process on techinterview.org describes the customer scenario round as the one candidates tend to underestimate, while Distyl weights it most heavily.

The same piece makes a point that should shape how you prepare: the interviewer will not volunteer details, and your score comes from the questions you ask and the order in which you ask them.

FDE Academy’s interview guide reduces what assessors want to learn in simulated customer sessions to a single question: do you take ownership, or do you deflect? The Distyl piece adds that ownership is examined in every round, including following a problem all the way to production rather than stopping at “it works on my machine”.

So do not prepare for this round as a system design exercise with some role-play on top. It tests whether, when a project gets stuck, you step up to unblock it.

Ownership does not mean having the answer straight away

Two pieces of advice sound contradictory. FDE Academy writes that, in a compliance-conflict question, the strong answer is to take on setting up the compliance review process rather than pushing responsibility back. The same source warns that jumping straight to a solution will fail you, every time.

In fact the two fit together, because what you own is the process, not yet the solution. You commit to being the person who leads the search for an approved path, but you do not claim to know what that path is before you know who blocked it, which data is affected and why.

The Distyl piece makes exactly this point: strong candidates define the problem clearly before discussing solutions.

There is one more line not to cross. FDE Academy advises never blaming the customer’s systems, even when that is precisely where the problem lies. “Your process is too slow” may be true, but it will cost you the goodwill of the person across the table, and quite likely points with the assessor.

One scenario, line by line

Back to the opening situation. What follows is a hypothetical script for practice, not a transcript of a real interview. Note the order of the questions: people first, then data, then the deadline.

Candidate: “Thanks for flagging this early. Just so I understand correctly: who in compliance made this decision, and did they give a clear reason?”

Customer: “Lan in legal. She’s worried about customer data leaving our systems.”

Candidate: “All of the data, or only certain fields? Phone numbers or account numbers, for example?”

Customer: “Mainly identifying information.”

Candidate: “And the go-live date next week: who is that commitment to? Could we launch part of it first, or does it have to be everything?”

Only now does the candidate restate the problem and take ownership: “So as I understand it, the sticking point is the identifying fields, not the whole project.

Here’s what I propose: today I’ll draft a data-flow description showing exactly which field goes where, and ask Lan for 30 minutes to agree the list of approval conditions together.

Leave the documentation and the meeting to me.”

The closing line is where the points are scored: “There are two risks I want to raise up front. If we mask the identifying data, quality on some tasks may drop, so we’ll need to measure it again. If Lan needs more time, I suggest going live first with the non-sensitive data, so that next week something is still running for real.”

Compared with an answer that pushes the work back, the difference lies in every sentence, not just in attitude.

Practise the five beats

The first beat is asking questions to scope the problem. Since the interviewer playing the customer will not volunteer information, prepare three groups of questions in advance: who decides, what exactly is in scope, and what the time constraints are. Aced’s guide to the ElevenLabs case study round likewise says assessors want to see you start with customer discovery before proposing anything.

The second beat is restating the problem in your own words, so the customer can correct you if you have misunderstood. The third is taking on a specific piece of work, with an owner and a date, rather than a vague promise such as “I’ll help out”.

The fourth beat is naming failure modes and trade-offs before you are asked. According to Aced, in Anthropic’s solution design round candidates must scope the problem themselves, raise the failure modes themselves and spell out the trade-offs; the “problem ownership” criterion scores precisely whether you do this without being prompted.

The final beat is agreeing the next step towards production, because that is where ownership is put to the test.

Throughout all five beats, keep your voice steady. Aced describes Cognition’s simulated customer call round as scoring separately whether you answer clearly and calmly on the call.

Mistakes that fail candidates

The most common mistake is treating “taking ownership” as “having the answer”. Keen to look proactive, candidates propose an architecture in their first sentence and fall straight into the trap FDE Academy warns about. The right order is questions first, then the process, and the solution last.

The second mistake is overreaching: promising to win over legal, or committing to hit go-live at any cost. Take on the work you control, such as documentation, meetings and fallback plans, not decisions that belong to someone else.

The third mistake is asking many questions in no particular order. Ten scattered questions still do not show that you are scoping the problem, and the Distyl piece is clear that the order of your questions is scored too.

This skill should also show up on your CV. When a job description mentions “ownership” or “customer-facing”, look in your experience for a time a project was blocked and you were the one who set up a process to unblock it. Write that line as what you took on, what blocker you removed, and how the system reached production.

In this round, the candidate who gets the offer is often not the one with the best answer. It is the one the customer, after fifteen minutes, trusts to see things through.