# FDE interview prep: enough DSA to pass, then focus on decomposition

> Databricks asks you to write a dictionary-processing function in a notebook. OpenAI sets an implementation task split into several parts. Palantir gives you 60 minutes of decomposition on a problem that leaves out information on purpose, and it does not care whether you know Dijkstra by heart.

Bản gốc: https://fdetimes.net/en/guides/fde-interview-prep-dsa-decomposition/

Your FDE loop is three weeks away. The usual software engineer's reflex is to open LeetCode, filter for Hard, and grind graphs and dynamic programming late into the night. If you are aiming for Databricks, OpenAI or Palantir, most of that effort goes into the part that carries the fewest points.

The interview questions themselves show why. FDE coding rounds at these companies feel more like a day on a customer site than a programming olympiad: write a function that processes data, build a feature, then change it when the requirements shift. You still need DSA, but only enough to get through the door.

This guide sets out what "enough" means. It then works through a sample problem from start to finish and shows how to spend the rest of your time on the parts that carry more weight.

## What does the FDE coding round actually ask?

According to Aced (formerly Exponent), the Databricks FDE coding round asks you to write a practical function in a notebook, at easy-to-medium difficulty. The problem is about processing data with dictionaries, strings and lists. There are no graphs and no segment trees.

At OpenAI, the FDE coding round consists of production-style problems: one large implementation task, sometimes split into several consecutive parts. You may use AI tools, and the accompanying advice is to share your screen and talk through your reasoning as you go. When a machine can write the loops for you, the way you think is what the interviewer can see most clearly.

Palantir takes the same direction. An analysis on techinterview.org notes that the company does not check whether you have memorised Dijkstra. Its online assessment also surprises many candidates because it is not a Codeforces-style problem set.

| Company | Coding round format | What to practise |
|---|---|---|
| Databricks | Practical function in a notebook, easy to medium | Dicts, strings, lists, grouping, sorting |
| OpenAI | One large implementation task, possibly in several parts, AI tools allowed | Code that is easy to change, explaining your reasoning out loud |
| Palantir | Online assessment not in the Codeforces style, plus a decomposition round | Open-ended problems, asking clarifying questions |

## Why "enough" is enough

According to techinterview.org, an FDE loop sets out to answer three questions and weighs them roughly equally. Can you write code? Can you find out what the customer really needs (scoping)? Can you reason when things are still ambiguous? Code is only one of the three.

The same source argues that the decomposition round counts for more than any coding screen in the loop. At Palantir it is a 60-minute pairing session, usually on CodePair, with a problem statement that deliberately leaves information out. The author's conclusion is blunt: if you only study algorithms, you are preparing for the least important part of the exam.

**Điểm mấu chốt:** The FDE coding round is the gate; most of the score comes from how you ask questions and break down the problem.

So "enough" can be defined precisely. You can loop over lists fluently, group with dictionaries, split and clean strings, sort with a custom key, and estimate the complexity of the code you have just written. Beyond that level, each extra hour of study adds very little to your score.

## Working through a notebook-style problem

Imagine a Databricks-style problem. A customer sends an activity log as a list of strings in the form `"user_id,action,timestamp"` and wants to know which actions each user performs most often. Before typing any code, ask: should malformed lines be skipped or should they raise an error? How should ties be ordered? How many actions should be returned per user?

Suppose the interviewer answers: skip broken lines, break ties alphabetically, return the top 3. A compact solution:

```python
def top_actions(lines, k=3):
counts = {}
for line in lines:
parts = [p.strip() for p in line.split(",")]
if len(parts) != 3 or not parts[0]:
continue  # bỏ dòng hỏng, như đã thống nhất
user, action, ts = parts
user_counts = counts.setdefault(user, {})
user_counts[action] = user_counts.get(action, 0) + 1
return {
user: sorted(acts.items(), key=lambda x: (-x[1], x[0]))[:k]
for user, acts in counts.items()
}
```

(The comment reads: "skip broken lines, as agreed.") The whole solution uses only dictionaries, strings, lists and one sort, exactly the scope Aced describes. The credit comes not from difficulty but from what you say while you write it.

Explain why you skip broken lines rather than let the program crash, why the sort key is a tuple, and why the complexity is O(n) for the counting step plus the sort for each user.

## When the requirements change mid-interview

OpenAI's problem may be split into several consecutive parts, so practise for the moment the requirements change too. Suppose part two is: "Now the customer wants to see this per day." A newcomer will immediately change the code to `ts[:10]` and run it. An FDE stops to ask: do the timestamps all share the same format, do they carry a time zone, and whose time zone defines a "day"?

Once you have the answers, the change is small: make the key a tuple `(user, day)` or add another level of nested dictionary. If part one was cleanly separated, part two needs only one edit, so keep the code simple from the start. If you use an AI tool to generate the change, read each line aloud and explain why you accept it.

This reflex is also the core skill of the decomposition round: take an underspecified problem, turn it into a few clear decisions, and only then start coding.

## How to split three weeks of prep

In the first week, spend a few sessions checking whether you are already at "enough": do ten to fifteen easy-to-medium problems on strings, dictionaries and sorting, in a notebook rather than in LeetCode's editor. If they come easily, stop there. The advice on techinterview.org is not to do another fifty LeetCode problems, but to practise open-ended ones.

In weeks two and three, practise decomposition in pairs. One person gives a vague, one-sentence problem; the other has 60 minutes to ask questions, break the problem down and code a working piece. Record the session and listen back for long silences or for assumptions you made without saying so.

Alongside this, read job postings closely. Anthropic's FDE posting asks for strong communication skills to run discovery with customers and to explain technical concepts to many kinds of stakeholders.

HackerRank's posting describes the right candidate as someone who enjoys combining engineering, consulting and delivery, and who owns every step from start to finish. If you are a developer working in outsourcing or on a product team, as many in Vietnam are, your CV should include at least one line about a time you clarified requirements with a customer yourself. Do not just list frameworks.

## Common traps

The first trap is diving into code as soon as you have read the problem. When a problem deliberately leaves information out, typing in silence means you have answered, on the customer's behalf, questions you should have asked.

The second trap is using AI without saying anything. When tools are allowed, a screen full of correct code with no explanation tells the interviewer almost nothing about how you think.

The third trap is the opposite: hearing that "DSA doesn't matter", dropping it entirely, then fumbling when you need to group with a dictionary. The screening round can still knock you out.

The last trap is over-engineering: building classes, interfaces and design patterns for a twenty-line function. In a multi-part problem, simple, cleanly separated code is usually easier to change than code with "elegant architecture".

Study enough DSA to get through the screen. After that, most of the outcome depends on the questions you ask before you type the first line of code.

**Thử ngay tuần này:**

- Open a notebook and, in 25 minutes, write a function that counts actions per user from a list of CSV strings, recording yourself explaining as you go
- Ask a friend to change the requirements partway through (for example, group by day) and practise asking at least three questions before you change the code
- Reread your CV and add a line describing a time you clarified an ambiguous requirement with a customer or stakeholder, and what came of it

## Nguồn

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

- [OpenAI Forward Deployed Engineer Interview (Aced, formerly Exponent)](https://www.aced.io/guides/openai-forward-deployed-engineer-interview)

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

- [Inside the Palantir engineering interview loop](https://www.techinterview.org/post/3233476805/palantir-interview-process/?format=md)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)