← Back to Directory

Dropbox interview notes, page 3 of 5

Large Enterprises

Most of these Dropbox write-ups come from Software Engineers (27), then Product Managers (13) and Data Scientists (4). The most reported rounds are the technical phone screen (15), the product sense round (12), the system design round (11) and the behavioral / leadership round (5).

46 interview notes · updated Jul 2026

Dropbox·Data Scientist·Technical Phone Screen

May 2026
Dropbox Data Scientist interview that went pretty deep into algorithmic territory. The main problem was a grid/island question with a bunch of follow-ups layered on top, and it felt more like a software engineering screen than anything data-sciency.
  • Given an n×n binary grid where 1 is land and 0 is water with 4-directional connectivity, return the size of the largest island you can achieve by flipping at most one 0 to 1. Your solution should run in O(n^2) time.
  • Follow-up: if you must flip exactly one 1 to 0, what is the minimum number of islands that can result? Describe an algorithm and its complexity.
  • Follow-up: if you can perform one 0-to-1 flip and one 1-to-0 flip on distinct cells in any order, what is the maximum possible largest island size? Prove optimality or provide a counterexample.
  • How would you handle edge cases like an all-zeros grid or an all-ones grid, recursion depth limits for large n, and adapting the solution for very large grids using chunking, streaming, or union-find labeling?

“I knew the general approach: label each island with a unique id using union-find or BFS, store each island's size, then for every 0-cell check its distinct neighboring island ids and sum their sizes plus one.”

View Post

Dropbox·Software Engineer·Onsite - Behavioral / Leadership

May 2026
Dropbox software engineer interview with a deep-dive behavioral question about your most complex project. The interviewer wasn't just looking for a story, they kept drilling until they found the edges of what you actually knew.
  • Walk me through the most complex project you've worked on, including the technical and business context, your specific contributions, the decisions you made, and the outcome.

“The part that gets people is 'your specific contributions.' I've seen folks (myself included at one point) describe the team's work and accidentally make it sound like a group effort where they were just along for the ride.”

View Post

Dropbox·Software Engineer·Onsite - System Design / Architecture

May 2026
Dropbox system design round focused entirely on file processing APIs, starting simple and then getting progressively harder. Two-part question that felt like a real engineering conversation more than a gotcha session.
  • Design a synchronous REST API for processing a list of files, where the client submits file IDs and gets back results for all of them in a single response. Include request/response format and high-level backend components.
  • Now assume file processing can take several minutes and the list could be large. Redesign the system to handle this asynchronously, including job submission, status tracking, result retrieval, idempotency, and reliability across crashes and restarts.

“Started with POST /processFiles taking a JSON array of file IDs, returns per-file results with status and any output or error.”

View Post

Dropbox·Product Manager·Onsite - Product Sense / Strategy

May 2026
Dropbox PM interview, got hit with a classic metrics/diagnosis question about a core product feature dropping. Pretty standard stuff but it moves fast if you're not warmed up.
  • Dropbox upload success rates have dropped by 50%. How do you investigate and respond?

“My first instinct was to jump straight to causes, which was probably the wrong move.”

View Post

Dropbox·Machine Learning Engineer·Technical Phone Screen

May 2026
ML engineer design question at Dropbox, basically one big open-ended problem about building a file recommendation feature for the mobile app. No behavioral stuff from what I remember, just deep on the system.
  • Design a recommender system that surfaces relevant files to users when they open the Dropbox mobile app.

“I jumped straight into collaborative filtering and the interviewer kind of just waited.”

View Post

Dropbox·Software Engineer·Onsite - System Design / Architecture

May 2026
Dropbox system design round, second part of a multi-session technical interview. The focus was on implementing an async file crawler with a real scaffold provided, so no setup busywork, just filling in the concurrent logic.
  • Given a scaffold for an async file crawler, implement the task scheduling, work queue, worker pool, and result aggregation, with correct handling of backpressure and graceful shutdown.

“The scaffold was actually a relief at first because I didn't have to argue about project structure.”

View Post

Dropbox·Software Engineer·Technical Phone Screen

May 2026
Dropbox coding round, extending a bank system with a ranking function. Pretty focused problem, felt like a Level 2 follow-up where they want to see if you can handle aggregation logic without getting sloppy about what counts as outgoing.
  • Given an existing bank system, add a topNOutgoing(n) method that returns the top N account IDs ranked by total outgoing spend. Only transfers and payments sent out should count, not incoming deposits or transfers. Break ties by account ID.

“The tricky part is being precise about what counts as outgoing.”

View Post

Dropbox·Product Manager·Hiring Manager Screen

Jun 2026
Interviewed for a PM role at Dropbox and got a pretty basic technical literacy question that I wasn't expecting to trip over as much as I did.
  • What is the difference between a POST request and a GET request?

“I knew this conceptually but fumbled the explanation a bit.”

View Post

Dropbox·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Dropbox system design round, no coding, just a whiteboard conversation about scaling a file crawler. The interviewer wanted to go pretty deep on every layer of the design and I felt underprepared for how far into the weeds they wanted to go on fault tolerance specifically.
  • You have a working single-machine file crawler that walks a directory tree and processes files. How would you scale it to handle a much larger workload? Walk through your concurrency model, how you'd partition the file space, queuing and dispatch, deduplication, fault tolerance and retries, throttling, and what metrics you'd track.

“This is basically a distributed systems design question dressed up as a file crawler question.”

View Post

Dropbox·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Dropbox system design round focused entirely on building a distributed file system crawler. Pretty deep dive, they wanted the full picture from APIs down to failure handling and client-facing progress reporting.
  • Design a distributed service that crawls a large file system from a root path, where a client can start a crawl job via API and background workers traverse directories asynchronously, recursively spawning child tasks as needed.
  • What does the data model look like for crawl jobs, individual crawl tasks, and the file metadata you discover along the way?
  • How do workers recursively schedule child tasks when they encounter subdirectories during a crawl?
  • How would you handle retries, idempotency, and deduplication so that partial failures don't corrupt the crawl state or cause duplicate processing?
  • How would you scale this system to handle very large directory trees with potentially millions of files and thousands of concurrent tasks?
  • How do you expose crawl progress and final results back to the client?

“This was the whole interview, basically.”

View Post