FDE interview prep: enough DSA to pass, then focus on 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.

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:

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.