← Back to Directory

Dropbox interview notes, page 5 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·Product Manager·Onsite - Product Sense / Strategy

Jul 2026
PM interview at Dropbox with a market sizing question about Airbnb's revenue. Pretty standard case-style prompt but it requires you to actually know how to structure a bottom-up estimate without falling apart mid-calculation.
  • Estimate Airbnb's annual revenue.

“I started with supply side (number of listings, occupancy rates, average nightly price) and worked toward a GMV number before applying a take rate.”

View Post

Dropbox·Machine Learning Engineer·Onsite - Behavioral / Leadership

Jul 2026
Behavioral research deep-dive for an MLE role at Dropbox. The whole thing was about an hour and they just kept pulling on the same thread, so you can't really rehearse your way out of it.
  • Walk me through a past research project. What problem were you solving and why did it matter?
  • What other approaches did you consider before settling on your method, and what made you choose the one you did?
  • How did you design and validate your experiments for that project?
  • What trade-offs did you make during the project and what drove those decisions?
  • What failed during the project and what did you take away from it?
  • If you were starting this project over from scratch today, what would you do differently?

“This is where I started strong but probably oversold the impact.”

View Post

Dropbox·Software Engineer·Technical Phone Screen

Jul 2026
Dropbox software engineer interview with a coding round built around implementing the core feedback logic for a Wordle-style game. Pretty clean problem once you break it down, but the misplaced match counting tripped me up at first.
  • Implement the feedback function for a word-guessing game: given a dictionary of valid words, a secret word, and a player's guess, return the number of exact position matches and the number of misplaced (right letter, wrong position) matches. Invalid guesses should be signaled clearly.

“The exact match part is straightforward, just zip the two strings and count.”

View Post

Dropbox·Software Engineer·Onsite - System Design / Architecture

Jul 2026
Dropbox system design round, one meaty question that took up the whole session. The problem sounds straightforward until you're actually in it trying to juggle concurrency, data structures, and distributed scaling all at once.
  • Design a key-value store that also tracks how many times each key has been accessed. It should support querying a key's hit count and returning the top-N most-accessed keys, both over all time and optionally over a sliding time window. Walk through your data structure choices, how you'd handle concurrency, and how the system scales horizontally.

“I started with the obvious hashmap for O(1) gets and a max-heap for top-N, which felt fine until they pushed on the sliding window part.”

View Post

Dropbox·Software Engineer·Technical Phone Screen

Jul 2026
Dropbox SWE interview with a file system access problem. Pretty well-scoped question but the follow-up about efficiency tripped me up more than I expected.
  • Design and implement a HasAccess function for a hierarchical file system where access to a folder is inherited by all its descendants. Given a set of directly accessible folders, return whether a user can access a given folder path.

“My first instinct was to just check if the path is in the set, which is obviously incomplete.”

View Post

Dropbox·Data Scientist·Technical Phone Screen

Jul 2026
Dropbox data scientist interview with a deep experimentation design question focused on their file recommender system. Single question but it covered basically every dimension of experiment design you can think of, from randomization unit to alpha spending to Simpson's paradox. Dense.
  • Design an online experiment to evaluate a file recommender system in production across multiple organizations, where users within the same org can influence each other's behavior. Cover: primary metrics, secondary metrics, guardrails, randomization unit, clustering and ICC assumptions for sample size, variance reduction, sequential monitoring, ramp schedule, novelty/carryover controls, logging for exposure and attribution, a difference-in-differences fallback if full randomization isn't possible, and stop/ship criteria including how to handle Simpson's paradox across tenants and roles.

“This was a lot.”

View Post