Interview Experience | Backend / Storage | π₯π₯ | Databricks
2026 (Oct) Senior Software Engineer, Backend (Files Team) @ Databricks β San Francisco, CA β Phone + VO β 2 rounds | π Neutral | Hard
Round 1 β Phone Coding
Code has to run, write your own tests.
Ordered list of rules like allow /ws/a/*, deny /ws/*. /x/* covers /x itself and everything under it. check(path): first matching rule wins, no match means deny.
Part 1: linear scan. I used startswith, he threw in /ws/ab/f and it matched /ws/a/*. Switched to comparing by / segments.
Part 2: tens of thousands of rules. Trie, rules on nodes, keep the smallest index on the way down. Two rules on the same prefix, the later one overwrote the earlier, only found it when a test failed.
Part 3: UI listing a directory. any_allowed(dir): show it if anything under it is readable, plus all_allowed(dir). I started with dfs over the subtree, he said dirs are huge. Stuck a while, his hint was "which rules never take effect". If an ancestor has a smaller index, the rule is dead, so only look at rules smaller than all their ancestors. Mark live rules once after building the trie, each node keeps whether the subtree has a live allow / deny, so a query walks a single path. Missed the case where the walk runs out of trie halfway, added after he pointed it out.
Part 4: rules added and removed online. Thought of an euler tour to flatten subtrees into ranges, couldn't figure out what to store per range. Didn't write it.
Round 2 β VO System Programming
Single machine, file metadata store for agents: put(path, meta) / get / delete / list(prefix). Pseudocode plus some real code.
In-memory: dict plus a sorted structure. Not much discussion.
Then a WAL. He pointed at the append line: "power goes out here, what state are you in". Half-written record is caught by length + crc per record, truncate at the first bad one on replay. Whether write() returning means durable got us into fsync, group commit only got a mention.
Next rename(dir, new_dir) with hundreds of thousands of files under it. I said log each put/delete, he asked what if we crash halfway and half are moved. Changed to a single mv record in the WAL.
WAL gets long so checkpoint: temp file, fsync, rename. Forgot to fsync the directory, he asked if the rename itself could be lost. Then: crash after the checkpoint is written but before the WAL is truncated. Replaying a put is fine, replaying mv twice is wrong. LSN on every record, checkpoint stores where it got to.
Last: multiple writers, and someone running list(prefix) while a rename is half done must not see half old half new. I said rw lock, he said a slow list blocks every writer. Started on MVCC, didn't get to when old versions can be dropped. Time was up.