The Databricks FDE interview: Spark, Unity Catalog and the round that turns a vague goal into a system

Picture the interviewer opening with one sentence: “A retail chain wants to use AI to retain customers. Design it.” No schema, no figures, and nobody mentions a deadline.

According to an interview guide from Aced.io, this is what the decomposition round at Databricks looks like: about 60 minutes to design a system from a business goal that is still vague.

The round is hard because it resembles the real job. Databricks’ Sr. FDE (Fullstack) posting says engineers will work with customers to build and take into production solutions to their data and AI problems. The responsibilities section states plainly that FDEs lead technical projects that produce production-grade systems.

So if you only grind LeetCode, you will fall short. The three things actually tested are a deep understanding of Spark, a grasp of governance through Unity Catalog, and the ability to turn a fuzzy request into an architecture. For each, the sections below include an example you can work through yourself.

Five rounds, but only three skills

The Aced.io guide describes a five-round process: 30 minutes with a recruiter, a technical screen, a coding round in a notebook, the decomposition round and a leadership round. This is a third-party description, not official documentation, so the order and duration may vary by hiring team.

More reliable is the list of requirements in the postings themselves. The posting for the Seoul role asks for extensive experience with distributed computing in Apache Spark and knowledge of Spark’s runtime internals.

It also asks candidates to understand and use MLOps, ML/AI models and AI APIs, and to be able to code in several languages. The senior posting in Zürich gives the FDE authority over architectural decisions, on the condition that solutions are secure and scalable.

Put the two sources together and the notebook round tests Spark, the decomposition round tests architecture and governance, and the leadership round tests how you work with customers. Prepare around those three skills rather than splitting your time evenly across five rounds.

Spark questions are really about what sits beneath the API

The phrase “runtime internals” means the interviewer wants you to explain why a job runs slowly, not just write a join. A classic example is data skew.

Say you join the orders table with the customers table on customer_id, and Spark splits the data after the shuffle into 200 partitions. If one wholesale customer accounts for 40% of the rows in orders, all of that 40% lands in a single partition. The result: 199 tasks finish in seconds, while the whole job waits on one task carrying nearly half the work.

A good answer has three steps. First, detection: in the Spark UI, one task’s run time is far longer than the others in the same stage. Next, the cause: the shuffle sends every row with the same key to the same place.

Finally, the fixes: broadcast the small table to avoid the shuffle, add “salt” to the skewed key to spread it across several partitions, or enable adaptive query execution so that Spark splits oversized partitions itself.

Do not just read this. Build a skewed table in a notebook and time the job before and after the fix. In the interview, describing it with numbers you measured yourself is far more convincing than reciting definitions.

Unity Catalog is the answer for whoever worries about security

Databricks’ documentation defines Unity Catalog as a unified governance layer for data and AI, built into the platform. There are two points you must be able to make the moment you are asked.

The first is the three-level namespace catalog.schema.object. In the retail problem above, the customer feature table might be named retail.churn.customer_features. Naming things this clearly on the whiteboard shows you have thought about where the data lives and who may access it.

The second is lineage. Unity Catalog automatically tracks how data and AI assets move and connect, from source data to models, services and dashboards. The benefit is concrete: when the marketing director asks where a dashboard number comes from, you can trace it back to the source table without reading code.

The first ten minutes decide the decomposition round

The Aced.io guide advises spending the opening minutes clarifying the goal, because the round stands in for a real customer meeting. For the “retain customers” brief, you might ask in this order:

“How is retention measured: the share of customers who buy again within 90 days, or average order value?” “Who uses the output: the marketing team sending weekly offers, or in-store staff?” “Where does the transaction data live now, and how often is it updated?” “Is there personal data that only some people may see?”

Suppose the answers are: marketing sends a campaign every week, the data updates nightly, and customer phone numbers are sensitive. Under those conditions the architecture almost draws itself.

Data is loaded nightly into the retail catalog, Spark computes features, a model scores churn likelihood, and the results are written to a table the marketing team can read. The phone number column is open only to the campaign operations group.

The diagram is only half the job; the other half is explaining why you chose this approach over another. For instance, you choose batch over streaming because campaigns run weekly, so real-time scoring would only add cost without adding value.

You add MLOps-style model monitoring because shopping behaviour shifts with the seasons. You point to lineage to show the system can be audited.

Pick the right posting before you apply

Databricks’ three FDE postings have clearly different emphases, and your CV should be written for each one separately.

	FDE (Seoul)	Sr. FDE – Fullstack (Zürich)	AI Engineer – FDE
Focus	Distributed computing with Spark, runtime internals	Production-grade systems, architectural decisions	GenAI applications
Experience to demonstrate	Deep Spark; MLOps, ML/AI models, AI APIs; coding in several languages	6+ years in data engineering, data platform & analytics or software engineering	RAG, multi-agent systems, Text2SQL, fine-tuning
Customer cadence	—	Leads customers’ technical projects	Visits customers every 4–8 weeks as needed

Whichever role you apply for, each CV bullet should state three things: a system you took to production, a measured number, and how you handled access control or data lineage. For example, “cut join time from X to Y by fixing skew” carries far more weight than “proficient in Spark”.

The mistakes that sink strong candidates

The most common mistake is drawing an architecture as soon as you hear the brief. The interviewer is playing the customer, and skipping the clarifying questions is like skipping discovery with a real client.

The second is answering Spark questions at the API level when the Seoul posting explicitly asks for runtime knowledge. The third is mentioning governance only when prompted, when the senior Fullstack posting requires solutions to be secure from the design stage.

In the leadership round, a generic story such as “I work well in a team” loses to one with a specific customer, a specific conflict and a decision you owned.

You do not need to know every Databricks feature by heart. You need to show the interviewer that if they sent you to a customer with a vague request tomorrow, you would ask the right questions, choose the right architecture and leave behind a system others can trace.