Game of Life (LeetCode 289): Given a board representing Conway's Game of Life, compute the next state of the board in-place.

The key insight is updating in-place without losing the original state by encoding two-state transitions in the cell value itself (e.g., use 2 to mean 'was alive, now dead' and -1 for 'was dead, now alive'). A second pass then normalizes to 0/1. Time O(m*n), space O(1). The common follow-up asks how you would handle an infinite or very sparse board, pushing toward a HashSet of live cells approach. Clean in-place mutation reasoning, correct neighbor counting (8 directions including diagonals), and the ability to extend to the infinite board variant without hand-holding.

Web Crawler Multithreaded (LeetCode 1242): Given a start URL and an HtmlParser interface, crawl all pages under the same hostname. First implement single-threaded, then extend to a thread-safe multithreaded solution.

Start with a BFS/DFS using a visited set and the HtmlParser.getUrls() call. The key insight for the multithreaded extension is using a thread pool (ExecutorService / ThreadPoolExecutor) with a concurrent visited set (ConcurrentHashMap or synchronized set) and a BlockingQueue or CompletableFuture fan-out. The tricky termination condition is knowing when all workers are idle with an empty queue. Follow-up often asks about rate limiting or politeness delays. Correct use of thread synchronization primitives, safe shared state, and the ability to reason about deadlock and termination conditions. Candidates who hard-code threads rather than using a pool get dinged.

Design Hit Counter (LeetCode 362): Design a class that counts hits received in the past 5 minutes. The hit(timestamp) and getHits(timestamp) methods receive monotonically increasing timestamps in seconds.

A circular buffer of size 300 is the canonical O(1) time, O(300) space solution: one array for timestamps, one for counts, indexed by timestamp mod 300. On each hit, if the slot's stored timestamp matches the current second, increment; otherwise reset. For getHits, sum only the slots whose timestamp falls within the last 300 seconds. Follow-up: handle concurrent hits (add locks or use AtomicInteger arrays), or handle non-monotonic timestamps (use a sorted map). Arrival at the circular buffer insight rather than a naive sliding window over a list. Ability to handle the wrap-around correctly and discuss trade-offs with a TreeMap approach for out-of-order timestamps.

Design Dropbox (or: Design a cloud file storage and sync service like Dropbox). Candidates are typically asked to design the file upload, download, and cross-device sync system.

Start by clarifying scale (billions of files, petabytes of data) and core requirements: upload/download, cross-device sync, sharing, and versioning. Split files into fixed-size chunks (commonly 4 MB) on the client before upload; this enables delta sync (only changed chunks re-uploaded), deduplication via content-addressed storage (hash of chunk), and parallel uploads. The metadata service (SQL DB with files, chunks, users tables) is separate from block storage (S3-compatible object store). Sync is driven by a change notification service (long-poll or WebSocket) that notifies clients of delta changes. Key trade-offs: strong vs. eventual consistency for sync, conflict resolution strategy (last-write-wins vs. version vectors), and storage deduplication at the chunk level. Follow-up: how do you handle offline edits that conflict when the client reconnects? Client-side chunking and delta sync insight (this separates strong candidates from average ones), separation of metadata and block storage, a concrete conflict resolution policy, and discussion of deduplication economics.

Design an In-Memory File System (LeetCode 588 / low-level design variant): Implement a file system with mkdir, addContentToFile, readContentFromFile, and ls commands operating on a virtual directory tree.

Model the file system as a trie where each node represents a directory or file. Each node stores its children (a sorted map for ls) and optionally file content. mkdir traverses or creates nodes along the path. addContentToFile creates nodes and appends content. ls returns sorted children if path is a directory, or the filename if it is a file. Time for each operation is O(L * log K) where L is path depth and K is max children per node. Follow-up: add permissions (store a user-to-permission map per node), or implement a delete operation that handles non-empty directories. Clean trie modeling, correct handling of paths (splitting on '/'), and the sorted ls output. Interviewers watch for whether the candidate naturally reaches for a trie or over-engineers with separate data structures.

Design a Notification Service: Design a system that reliably delivers push notifications to millions of users across iOS, Android, and web platforms, with support for user preferences and delivery guarantees.

The core pipeline is: producer service publishes events to a message queue (Kafka); notification workers consume and fan-out to platform-specific push services (APNs, FCM, Web Push); a user-preference store (Redis or Cassandra) gates delivery per user and channel. Reliability requires at-least-once delivery from the queue with idempotent push calls. Rate limiting per user prevents spam. For scale, the fan-out for a single event to millions of subscribers requires pre-computing recipient lists or using a tiered fan-out (hot users vs. cold users). Follow-up: how do you handle failures when APNs is down, and how do you track delivery receipts? Message queue decoupling, awareness of platform-specific push gateway constraints, idempotency to handle retries, and a concrete plan for the fan-out scalability problem.

Tell me about the most impactful project you have led. Walk me through the technical decisions you made, how you collaborated with the team, and the tough calls you had to make.

Use a structured narrative: set up the business context and why it mattered (Aim higher), describe 2 to 3 concrete technical decisions with the alternatives you considered and why you chose what you did, name specific teammates and how you influenced them without authority (We not I), and close with quantified impact. Dropbox places particular weight on ownership and proactivity, so emphasize decisions you drove rather than ones made above you. Interviewers probe for depth by asking 'why did you choose X over Y' so prepare to defend every architectural decision. Evidence of genuine ownership and technical depth. Interviewers listen for vague team credit ('we built it') versus specific personal contributions, and they probe for trade-off reasoning rather than accepting high-level descriptions.

Tell me about a time you had a conflict with a colleague or someone on a cross-functional team. How did you resolve it, and what did you learn?

Pick a real technical or prioritization disagreement, not a personality clash. Set up the stakes clearly (what was at risk if unresolved), describe your specific actions to understand the other person's position before advocating for your own (active listening, written proposals, bringing in data), and land on a concrete resolution. Close with what you learned and how it changed your approach to future disagreements. Avoid: making the other party look incompetent, or presenting a resolution that was simply capitulation. Emotional maturity, willingness to change one's mind given new information, and constructive rather than avoidance-based conflict resolution. This maps to Dropbox's 'We not I' and 'Make work human' values.

Describe a time when you received critical feedback that was difficult to hear. What was the feedback, how did you respond, and what changed afterward?

Choose feedback that was substantively about your technical or leadership approach, not just style. Demonstrate that you separated your ego from the message, sought to understand the root cause (asked clarifying questions, gathered data), made a concrete change, and followed up to close the loop with the feedback-giver. Candidates who describe feedback as 'I was told to communicate more' without a specific story tend to score low. Tie the outcome to measurable improvement. Self-awareness and growth mindset. Dropbox specifically probes for candidates who respond to feedback with curiosity rather than defensiveness, which aligns with the 'Own it' value.

Dropbox Interview Questions

Dropbox's SWE interview process runs roughly 3 to 5 weeks and consists of a CodeSignal online assessment (4 tasks, 90 minutes, building a system progressively), followed by an onsite split into two sets. The first set has two 1-hour coding rounds and a 1-hour project deep-dive; the second set (used for leveling) adds a 1-hour system design round and a 1-hour behavioral round with the hiring manager. Senior candidates (IC-5 and above) face a heavier system design emphasis and are expected to perform at a Staff-equivalent bar. The coding rounds notably favor practical, real-world OOP and concurrency problems over pure algorithmic puzzles, and the web crawler and Game of Life questions have been explicitly called out as "extremely popular" in first-hand prep materials sourced from Dropbox employees.

17 real questions across 3 rounds

Reported via LeetCode Discuss threads (dedicated Dropbox phone screen Game of Life threads, Hit Counter thread, Find Duplicate File tag); GitHub insideofdrop/Dropbox-Interview-Prep README (sourced from Dropbox engineers, labels Game of Life 'EXTREMELY popular phone screen', Web Crawler 'EXTREMELY popular onsite', ID Allocator 'extremely popular most onsites'); Glassdoor interview question posts (LRU Cache QTN_557872, Token Bucket QTN_1747897); algo.monster Dropbox LeetCode tag list; Exponent Dropbox interview guide; YouTube 'Dropbox Coding Interview Question Leetcode 1242 Web Crawler Multithreaded'

Run a Dropbox mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews