← Back to Directory

Databricks interview notes, page 13 of 22

Large Enterprises

Most of these Databricks write-ups come from Software Engineers (192), then Machine Learning Engineers (9) and Data Scientists (8). The most reported rounds are the technical phone screen (136), the system design round (57), the behavioral / leadership round (9) and the onsite coding round (6).

216 interview notes · updated Jul 2026

Databricks·Software Engineer·Onsite - Coding / Algorithms

May 2026
Two coding problems for a Databricks software engineer round, one graph theory problem that sounds deceptively simple and one grid pathfinding problem with progressively nastier follow-ups. The uniformity requirement on the first one is where things get interesting.
  • Given k disjoint groups of node IDs where each group is already internally connected, return exactly k-1 edges that connect all groups into one component. The catch: the result must be sampled uniformly at random over all valid minimal connecting edge sets, and you need to explain why naive approaches fail to achieve uniformity.
  • On a 2D grid with start, destination, obstacles, and cells labeled by transportation mode (walk, bike, car, train), each mode has a per-step cost and time. You must pick one mode for the entire trip and can only traverse cells of that mode type. Return the mode with minimum total travel time, breaking ties by cost.
  • Extend the grid problem to allow switching transportation modes mid-route, where each switch incurs a penalty. Find the optimal path minimizing total time then total cost.
  • Further extend the problem to cap the number of allowed mode switches. Find the optimal route under the same objective while staying within the switch limit.

“I got the basic structure fast, pick a spanning tree over the groups and for each tree edge pick one node from each endpoint group.”

View Post

Databricks·Software Engineer·Technical Phone Screen

May 2026
Databricks system design round focused entirely on one meaty problem: build a snapshot-able set with MVCC semantics. The whole session was basically a deep dive into one data structure, which I wasn't expecting from a coding-style round.
  • Design a snapshot-able set backed by MVCC. The API needs add, remove, takeSnapshot, get (returns elements at a given snapshot), contains (value + snapshotId), and an iterator over elements present at a given snapshot. Walk through your data structure choices, how you keep snapshot creation cheap, iterator stability guarantees, and the complexity of each operation.

“I started with the naive approach of copying the whole set on each snapshot and they shut that down immediately, which I kind of expected but still felt embarrassing to say out loud.”

View Post

Databricks·Software Engineer·Technical Phone Screen

May 2026
Databricks software engineer screen that came down to a single coding problem on run-length encoding. Pretty straightforward as far as these things go, though the follow-up complexity questions tripped me up a bit.
  • Implement run-length encoding and decoding for a string of lowercase letters. The encode function should compress consecutive repeated characters into character-count pairs, and decode should reverse that. Also walk through time and space complexity for each, and handle edge cases like empty strings or single-character runs.

“The encoding part was fine, just iterate and track the current character and a counter.”

View Post

Databricks·Software Engineer·Technical Phone Screen

May 2026
Databricks SWE interview with a graph traversal problem I'd seen referenced on forums before. Nothing too wild, but the multi-mode constraint adds a layer that trips you up if you try to be clever about it.
  • Given a 2D grid with a start and destination cell, four movement modes each allow traversal through different sets of cells. Each mode has a fixed per-step time and cost. Find the mode that minimizes total travel time; break ties by minimum cost.

“My first instinct was to try some unified search that mixed modes, which would've been a mess.”

View Post

Databricks·Software Engineer·Technical Phone Screen

May 2026
Interviewed for a data engineer role at Databricks, just one question from what I can tell. Short and technical, felt more like a screen than a full round.
  • In what scenarios would you choose a job cluster over an all-purpose cluster?

“I knew the surface answer but fumbled explaining the cost angle clearly.”

View Post

Databricks·Software Engineer·Onsite - System Design / Architecture

May 2026
Databricks system design round, one big question about building an online bookstore end to end. Pretty thorough scope, they wanted everything from search to payments to recommendations, so it was a lot to cover in one session.
  • Design an online bookstore system covering browsing, search, cart and checkout, order tracking, reviews, and recommendations.

“Big question.”

View Post

Databricks·Data Scientist·Technical Phone Screen

May 2026
Databricks data scientist interview with a meaty coding/SQL problem around nearest-neighbor matching across two datasets. The question had a lot of moving parts and the discussion went pretty deep into metric tradeoffs.
  • Given a source table and a target table that share the same numeric feature columns, write Python or SQL to find the top 5 most similar rows in target for each row in source. You need to define your similarity metric, explain how you handle NULLs, and output source_id, target_id, distance, and rank.
  • What are the tradeoffs between using MSE versus RMSE as your distance metric here, and would you consider any alternative metrics like cosine distance or Manhattan distance?

“This took me longer to set up than I expected, mostly because of the NULL handling piece.”

View Post

Databricks·Software Engineer·Technical Phone Screen

Jun 2026
Databricks technical phone screen for a software engineer role. The problem was a tree traversal question but with a twist that made it way harder than it sounds on the surface.
  • Given a Fibonacci-structured binary tree where each node's subtree sizes follow the Fibonacci sequence, find the path between two specified nodes without building the actual tree in memory.

“My first instinct was to just construct the tree and do a standard LCA traversal.”

View Post

Databricks·Software Engineer·Technical Phone Screen

Jun 2026
Databricks SWE interview that went deep on compression algorithms, covering both run-length encoding and bit-packing from scratch. Two related problems, more implementation detail than I expected, and the complexity analysis at the end caught me a little flat-footed.
  • Implement RLE compression and decompression for an ASCII string, where consecutive runs of the same character are encoded as a count followed by the character. Handle edge cases like empty strings, single characters, and runs with counts larger than 9 or 255.
  • Describe the time and space complexity of your RLE compression and decompression implementations.
  • Implement bit-packing compression for an array of integers in the range 0 to 15, packing two 4-bit values into each byte, with the first value in the high bits and the second in the low bits. Handle odd-length arrays by zero-padding the last byte.
  • Implement the inverse bit-packing function that reconstructs the original integer array from a packed byte array, given the original length n.

“I jumped straight into the happy path and forgot about multi-digit counts for way too long.”

View Post

Databricks·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Databricks system design round for a software engineer role. The whole thing was a deep dive into designing a thread-safe buffered writer with a background flush thread, covering API design, concurrency, flush policy, backpressure, and durability. Pretty intense for a single question but they clearly wanted to see how far you could push a design.
  • Design a BufferedDiskWriter component where many producer threads can concurrently append records, but a single dedicated flusher thread is responsible for actually writing data to disk. Walk through the API, concurrency model, in-memory data structures, and how producers hand off records to the flusher without serializing on a global lock.
  • What clarifying questions would you ask before designing this system? Specifically around durability contracts, ordering guarantees, crash loss tolerance, backpressure policy, and on-disk record framing.
  • When should the flusher thread actually flush, and what do you do when producers are generating records faster than the disk can absorb them? How do you prevent unbounded memory growth?
  • What durability guarantee does your design actually provide, and how do you handle failure scenarios like a slow disk, a write or fsync error, a mid-write crash, and a clean shutdown?
  • How would you implement a flush() that a producer can await until its records are confirmed durable, without blocking other producers in the meantime?
  • If the single flusher thread plus fsync becomes a bottleneck, how would you scale write throughput, and what ordering guarantees would you have to give up?
  • How would you make this component observable in production, and which metric would you prioritize for alerting?

“This is the core of the whole interview.”

View Post