# FDE interviews: the coding round survives, but it is no longer the main filter

> Cognition has reportedly dropped coding and system design altogether. Where coding rounds remain, the round that counts most is 45 to 60 minutes with a "customer" who holds back information on purpose.

Original: https://fdetimes.net/en/analysis/fde-interview-decomposition-round/

According to an interview guide from Exponent/aced.io, Cognition's hiring process for forward deployed engineers drops the two rounds that engineers aiming for big tech often spend a year preparing for: coding and system design. The final rounds are instead live customer simulations, such as pitching a proposal to an executive or a call to analyse a case.

Many will read this as "FDEs don't need to be strong coders". That reading is wrong. At Distyl AI and Databricks the coding round still exists, but it has changed in nature and is no longer the main filter.

The round that carries the most weight is the one in which the interviewer plays the customer and presents a brief that is deliberately incomplete. If you have put hundreds of hours into LeetCode to prepare for a move into FDE work, those hours will earn you fewer points than you think.

The good news is that the skill scored most closely can be practised. Few people practise it deliberately.

## Cognition is the exception, not the rule

Distyl AI still has a coding round. An analysis on techinterview.org of how the company hires FDEs advises candidates to prepare Python and notes that the problems will closely resemble day-to-day work. The round tests whether you can do the job of an engineer embedded at a customer, not whether you know algorithms.

Databricks is heading the same way. According to the Exponent/aced.io guide, the graph, algorithm and concurrency problems familiar from Databricks' software engineer interviews rarely appear in its FDE loop. In their place, the process adds a separate decomposition interview.

A post on the AI Engineering Insider Substack sums up the trend as "less LeetCode, more practical engineering", with coding problems such as parsing a messy CSV file or writing a rate limiter.

Educative's FDE course lists customer simulation as one of four round types that appear consistently in FDE hiring, in a process that typically runs to 4 to 6 rounds over 3 to 5 weeks.

Cognition dropping code is therefore the most extreme case of a broader trend. Code is still tested to check that you meet the bar, but whether you get the offer is decided in a different round.

## The real filter often contains no code at all

The Substack post calls the decomposition round the main filter outright. The candidate receives an ambiguous business problem with no clear spec, works on it for 45 to 60 minutes, and there is no single correct answer.

According to techinterview.org, this round usually involves no code: a hypothetical customer hands you a fuzzy problem and waits to see how you handle it.

The format is not new. According to an aced.io guide to decomposition questions, Palantir invented and popularised it, and many companies hiring FDEs now run their own version.

What makes the round hard is that the brief is incomplete by design. The aced.io guide states that working out which scope, constraints, data and success criteria are missing is itself part of what gets scored.

At Distyl, the interviewer playing the customer will not volunteer extra detail, so candidates are scored on the questions they ask.

**Key point:** In a decomposition round, the hidden information is the test: your score depends on discovering what is missing.

## What do interviewers score when there is no code?

According to techinterview.org, interviewers score four skills: structured problem decomposition, empathy for the end user, data-driven reasoning and judgement on scope. None of these shows up in a function that runs correctly. All of them show up in the questions you ask and the order in which you ask them.

The most common mistake, according to the same source, is proposing a solution as soon as the brief has been read, before asking who the user is and what "done" means. This is a natural reflex for good engineers. Years of being rewarded for solving quickly teach you to assume the problem as stated is correct and complete.

Consider a hypothetical scenario. The "customer" is a logistics company that says it wants to use AI to reduce late deliveries. An inexperienced candidate goes straight to a model for predicting delivery times, a data pipeline and a deployment plan. The answer sounds highly technical, but it may be solving the wrong problem.

A strong candidate asks first. Who is hurt when an order is late: the end customer, the driver or the customer service team? What counts as late? Where does the trip data live, and how clean is it? Three months from now, which number would show that the project has succeeded?

The right answer might need no AI at all, just an early warning sent to dispatchers.

Guidance for the Databricks decomposition round gives a concrete figure: spend the first 5 to 15 minutes clarifying the business goal, and only then move on to technical design. Skipping exactly this questioning step is what techinterview.org calls the most common mistake.

## Three companies, three weightings

Setting the three processes side by side shows that companies are not abandoning technical skills. They are shifting weight towards judgement.

| | Cognition | Distyl AI | Databricks |
|---|---|---|---|
| Coding round | Reportedly drops both coding and system design | Still included, in Python, close to day-to-day work | Graph, algorithm and concurrency problems are rare |
| Customer-centred round | Final rounds are live customer simulations: pitching to an executive, case analysis calls | Decomposition, with the interviewer playing the customer, treated as a key round | A separate decomposition session, starting from a business goal |
| What to prepare | Presenting and handling situations in front of a customer | Asking questions, because the interviewer will not volunteer detail | Spending the first 5 to 15 minutes clarifying goals before designing |

All three put the candidate in front of a customer who does not yet know clearly what they need. The only difference is how much code they still want to test alongside that.

The design makes sense. An FDE who codes a little more slowly than colleagues can still deliver a project. An FDE who builds an elegant system that solves the wrong problem makes the project fail, and that failure happens in front of the customer. Interviews are concentrating on the second kind of risk.

## What should career switchers practise?

For many developers, especially those working in outsourcing, as many in Vietnam do, requirements arrive through a business analyst or project manager as pre-written tickets. You may be very good at turning a spec into code, yet rarely have to ask the customer whether the spec is right. The decomposition round tests precisely the skill you use least.

This skill can be trained, and in the same way you once trained for LeetCode: with problems, a timer and someone scoring you. Ask a colleague to play the customer, tell them to answer only when asked, and then assess yourself against the four criteria above. After five or six sessions you will see how strong your reflex to propose solutions early really is.

Do not drop code entirely: Distyl still runs a Python coding round, and descriptions of FDE interviews show that coding problems are now practical engineering rather than LeetCode. Change how you practise instead: fewer algorithm puzzles, more tasks such as parsing dirty data, writing a rate limiter or calling an API with retries, and write them as code that will run at a customer site.

When reading a job description, look for words such as "decomposition", "customer simulation" or "case study". They tell you which round will carry the most weight. On your CV, instead of writing "developed module X in Python", describe a time when the initial requirement was vague: what you asked, how the scope was agreed and what the outcome was.

An FDE recruiter reading that line will see exactly the skill their interview is looking for.

The coding round has not disappeared, but it now only tells the company whether you meet the bar to continue. To get the offer, you need to perform well in the conversation with a hypothetical customer who does not yet know what they need.

**Try this week:**

- Ask a colleague to play the customer, give you a brief along the lines of "we want to use AI to reduce X", and answer only when asked. Time the first 15 minutes: during that window you may only ask questions, not propose solutions.
- Write a Python script that parses a dirty CSV file with missing columns, mixed date formats and duplicate rows, then review it as you would review production code.
- Rewrite one bullet point on your CV using this structure: how vague the initial requirement was, what you asked, how the scope was agreed, and the final result.

## Sources

- [Cognition Forward Deployed Engineer Interview (Exponent/aced.io guide)](https://www.aced.io/guides/cognition-forward-deployed-engineer-interview)

- [What the forward deployed engineer interview really tests](https://www.techinterview.org/post/3233477236/forward-deployed-engineer-interview/)

- [How Distyl AI hires forward deployed engineers](https://www.techinterview.org/post/3233477242/how-distyl-ai-hires-forward-deployed-engineers/)

- [Databricks Forward Deployed Engineer Interview (Exponent/aced.io guide)](https://www.aced.io/guides/databricks-forward-deployed-engineer-interview)

- [How to Answer Decomposition Interview Questions: The Definitive Guide (2026)](https://www.aced.io/blog/how-to-answer-decomposition-interview-questions-the-definitive-guide-2026)

- [The four interview rounds (Educative, Forward Deployed Engineer course)](https://www.educative.io/courses/forward-deployed-engineer/the-four-interview-rounds)

- [Cracking the Forward Deployed AI Engineer Interview](https://aiengineeringinsider.substack.com/p/cracking-the-forward-deployed-ai)