HackTheRounds Interview Experiences

Dropbox SWE Intern Interview Experience (2026) - CodeSignal Candy, SQL Retention, Find Duplicate Files

Dropbox Canada SWE intern loop: CodeSignal OA with Candy two pass greedy, SQL retention, pandas groupby, onsite coding duplicate files, deep dive, and values be

By Anonymous · 2026-03-26

Background

Dropbox has always been the company I pointed to when someone asked me which tech company I most respected on the systems side. File sync is deceptively hard, the product is beloved, and the engineering blog is a goldmine. I applied for the Summer 2026 SWE intern position in Canada through my university career portal and moved through the process on the CodeSignal plus video-onsite track. I am writing this before hearing the final decision, so the outcome is still open.

Timeline

CodeSignal OA (70 min)

The OA mixes a coding problem, two SQL problems, and a pandas data problem. Time is tight. I saw three other people in my cohort run out of minutes on the last pandas question because they over-engineered the SQL.

Coding — Candy Distribution

Problem: There are n children in a row, each with a rating. You must distribute candies so that every child gets at least one, and a child with a strictly higher rating than a neighbor gets strictly more candy than that neighbor. Return the minimum total candies.

This is the LeetCode Hard "Candy" problem. The clean solution is the two-pass greedy: left-to-right pass increments candy count whenever the current rating is higher than the previous; right-to-left pass does the same; final count at each index is the max of the two passes. Sum and return. O(n) time and O(n) space, reducible to O(1) extra with a stack-based one-pass but the two-pass version is safer under time pressure and it is what the grader seems to reward. The corner case is a strictly monotonic sequence at either end, which both passes catch naturally.

I spent about 12 minutes on this and had 58 left for SQL and pandas. If you have never seen the two-pass Candy trick before, the on-the-spot derivation is hard, so prep it.

SQL — New-User Counts and Retention

Problem 1: Given a db user table with registration timestamps and country, return the count of new user registrations per country per month for Q1 2021.

Straightforward GROUP BY country, MONTH(reg date) with a WHERE clause filtering to the first quarter. The trap is getting the month boundary right. I used a half-open range, reg date greater than or equal to Jan 1 and strictly less than Apr 1, to avoid date-function portability issues.

Problem 2: Return the retention rate of users who registered in January 2021 and were still active in February 2021. Active is defined by at least one row in db engagement .

LEFT JOIN of db user against the February-engagement rollup. COUNT over the non-null join output divided by the total January registrants. The trap is COUNTing the wrong column, because LEFT JOIN preserves non-matches and you will count too many rows if you COUNT( ). Use COUNT(DISTINCT user id) on the joined side.

Pandas — Country With Most Contracts (Alphabetical Tiebreak)

Problem: Given a CSV of customer data with a country column and a per-row contract count, return the country with the most total contracts. On ties, return the alphabetically last country.

groupby('country')['contracts'].sum() , sort by two keys in order: total contracts descending and country descending. Take the first row. The specific tiebreak rule where Z beats A is worth re-reading twice because most problems tiebreak alphabetically ascending, and if you default to ascending you will get half the test cases wrong.

First Onsite — Coding Round (60 min)

One medium-level algorithm problem with a chain of follow-ups that got progressively harder.

Problem: Given a list of file paths and their contents as strings, group the paths that have identical content. Return groups with more than one file.

This is the "find duplicate files in a system" problem. The direct approach is a hashmap keyed by content string with a list of paths as the value, iterate once, return values with length more than 1. O(total content size) time.

The follow-ups escalated. First follow-up: content can be multi-megabyte, you do not want to hash the full content for every comparison. Answer: hash in blocks or use a cryptographic digest of the full content once, key the map by the digest. Second follow-up: you have 10 million files on disk, you cannot load them all into memory. Answer: index by file size first (size is free from the filesystem), then only hash content for files that share a size, which cuts reads dramatically. Third follow-up: what if two different files produce the same digest. Answer: on a digest match, compare bytes directly as a tiebreak because collisions are possible, even if rare with SHA-256.

Second Onsite — Technical Deep Dive (45 min)

This round goes into resume projects and system design. I was asked about my largest project (a file-sync client for my research lab) and the interviewer pulled on every design decision. Why did I choose inotify over polling. What was my conflict resolution strategy and why. How did I handle renames versus copies in the delta encoding.

The small design portion was "design a simple file-sharing system with permission control, like a tiny Dropbox." The discussion was permission data model (per-folder ACLs with inheritance), authorization enforcement (gateway layer with a cache keyed by user plus resource), and what happens when a parent folder's permission changes and a child has an explicit override. That override-vs-inheritance conversation took the last 15 minutes.

Third Onsite — Behavioral (45 min)

Dropbox interviews on values explicitly: Trust, Impact, Collaboration. The interviewer pulled two stories from my resume and dug into each for 10 to 15 minutes, asking follow-up after follow-up on specifics. "What did you actually do that week? What was the one line of code that fixed it? What would you do differently?"

The consistency check is real. I felt the interviewer comparing my story-level details against my implementation-level details and flagging anything inconsistent. One of the candidates in my cohort told me they got rejected after this round because they had inflated the scope of a project and could not answer the implementation follow-ups.

Result

Awaiting decision as of writing. The recruiter said decisions go out within two weeks of the final round. I will update this post if the outcome lands while it is still timely.

Tips

  1. Drill the two-pass Candy greedy before your CodeSignal. It is the classic trap problem in Dropbox's OA and it is not intuitive on the first attempt. Do it once cold, then check your solution against the reference, then redo it without looking.
  2. Date filtering in SQL: use half-open ranges. Dropbox SQL graders love edge-of-month timestamps. Greater-than-or-equal lower bound, strictly-less-than upper bound. Never `BETWEEN` on date ranges.
  3. Read the pandas tiebreak rule twice. Dropbox flipped the default expectation on me. Problems that tiebreak alphabetically descending read the same as ascending at a glance, and one wrong sort direction costs you the entire test case.
  4. Size-first deduplication is the expected optimization. Every Dropbox coding round I know of that asks about duplicate files wants to hear "index by size first, then hash only within same-size buckets." If you skip this and go straight to hashing, you will lose the follow-up points.
  5. Dropbox values interview is a consistency check. They will pull the same story from two angles and cross-reference. Do not inflate a project. Pick a story you actually did end-to-end and prep the implementation details cold.
  6. For the small system design, permission overrides are the interesting part. Generic ACL answers do not pass. Have a concrete story about how explicit overrides interact with inheritance and what you do when the parent's permission changes.

Dropbox's loop rewards breadth over raw algorithm-speed. OA hand speed, clean SQL, genuine system-design opinions, and consistent behavioral stories. I have not heard back yet, but regardless of the outcome I found this loop more pleasant than most. Good luck to anyone going in.