Arrays, Strings & Hashing

The loud Dropbox coding signature is the multi-level build, one stateful class grown across four escalating requirements. Underneath that headline sits a quieter layer that decides whether you ever reach level two: arrays, strings, and hashing. This is the substrate the OA's algorithmic slot draws from, the material a phone screen leans on, and the set of primitives every applied build assembles. A file-path resolver is a stack. A top-spender ranking is a heap over a hash map. Grouping duplicate files is a dictionary keyed on content. Learn this band well and the rest of the loop stops feeling exotic.

Hashing carries extra weight here for a reason that runs straight through the product. Dropbox stores files as content-addressed blocks. It chops a file into roughly four-megabyte chunks and hashes each one. If two chunks hash to the same value, it stores the bytes once and points both references at the single copy. That is deduplication, and it is a hash map at planetary scale. So when an interviewer hands you a problem about grouping records by their content, you are rehearsing the company's core storage trick on a whiteboard.

The Dropbox angle

A hash map keyed on content is the primitive Dropbox is built on, so the grouping and dedup problems are not incidental. The block store hashes every chunk and collapses identical ones to a single stored copy; the sync engine compares hash lists to figure out which blocks changed. When a coding round asks you to bucket files by what is inside them, or to fold a stream of counts into a rollup, you are working the same idea. The infrastructure runs it billions of times a day. Reach for the dictionary early, name your key precisely, and say what a collision would mean. In the real system, a hash collision is exactly the case the durability layer has to reason about.

• Center of mass: Medium, applied. The median problem in this band is a clean medium. Difficulty comes from the real-world framing, the edge cases, and the requirement that gets added after your first version runs, not from an exotic algorithm.
• Where it runs: CodeSignal, timed. The first gate is a proctored CodeSignal assessment, roughly 70 minutes, auto-graded on hidden test batches. Get the main path passing, then widen to the edges before the clock closes.
• What is graded: Correct, clean, extensible. Dropbox runs a dedicated code-review round, so readable, well-named code that survives a follow-up is the currency. A structure that has to be ripped out at the next requirement costs you.
• The flavor: Files, paths, content. Dropbox is a file company, so its bank skews toward parsing, path normalization, and content-keyed grouping. The same fundamentals recur, framed as something the product does.

The families that recur

Three shapes cover most of what lands in this band. Each has one trigger, one structure it wants, and one Dropbox-flavored twist the interviewer tends to add. Learn to name which one you are in before you start typing.

Content-keyed grouping and dedup

Collapse a nested rescan into one pass by remembering what you have already seen under a well-chosen key. Two Sum remembers the complement it still needs. Group Anagrams keys on the sorted letters so every anagram lands in the same bucket. The Dropbox specialty is grouping files by their contents so you can find the duplicates, which is deduplication stated as a coding problem. Build a map from content to the list of paths holding it, then report every bucket with more than one path. The whole difficulty is choosing the key. When the values are large, the key should not be the raw content but a hash of it, which is the exact shortcut the block store takes with real files.

String parsing and namespace rollups

A parsing problem hands you structured text and asks you to tokenize it, then aggregate. Dropbox likes these because paths and namespaces are text with structure. Subdomain Visit Count takes counts attached to dotted domain names and rolls each count up every suffix, so a hit on mail.google.com also credits google.com and com. Swap dots for slashes and you have the folder-tree version. A write inside a deep folder increments the byte total of every ancestor up to the namespace root. That is how a metadata service answers "how big is this shared folder" without walking the subtree on every request. The skill graded here is careful tokenizing, the right split boundary, and accumulating into a map instead of a nested loop.

Sliding windows and two pointers

A window expands and contracts over a contiguous run while you track a small piece of state: a set of seen characters, a frequency map, a running count. Longest Substring Without Repeating Characters grows the right edge and, on a repeat, jumps the left edge past the previous occurrence, so both edges only ever move forward. That forward-only discipline is worth internalizing. It is how Dropbox's sync engine scans a file: a single control thread walks the byte stream once, deciding chunk boundaries as it goes and never rewinding. When the window state is a distinct-value count instead of a set, the same skeleton answers "longest run with at most K distinct values," which is the family's most common follow-up.

The Dropbox angle

Say your structure choice before you type it, because Virtual First makes clear written and spoken reasoning a graded signal. The loop is fully remote. Interviewers weight how well you narrate a decision, not just whether the code runs. Name the key you are hashing on, state the window invariant you are holding, and flag the edge case you are about to handle. That habit is the same one the code-review round tests from the other side, where you reason about someone else's code in plain words. A clean sentence about why a hash key survives large files carries real weight, and it costs almost nothing.

One more habit separates the solutions that pass from the ones you have to rewrite: patience with the prompt itself.

The Dropbox angle

Read the whole problem before you commit a data structure, because a Dropbox problem almost always grows one more requirement. The OA is engineered this way on purpose. A shortcut that passes the early levels gets invalidated by a later one, which demands a transaction history or a time-travel query you never built. The same reflex pays off in this band. If duplicate-file grouping might extend to "now the files are gigabytes," a map keyed on raw content was the wrong start and a hash key was the right one. State your structure choice and why it survives the likely next ask, then write it. That single sentence is what the code-review round is looking for.

Asked at Dropbox

One problem from each family: content-keyed grouping, a namespace rollup, and a forward-only window. Each test case is the function's arguments as a JSON array and the expected return. Write the base version and run it, then read the walkthrough, which carries the Dropbox follow-up the rest of the way.

1

Find Duplicate File in System: Group by Content

MediumFrequently asked

Problem

You are given a list of directory entries. Each entry is a string of the form "directory_path file1.txt(content1) file2.txt(content2) ...": a directory path, then one or more files, each written as its name immediately followed by its content in parentheses. Group together all files that share identical content and return every such group. Each file is reported as its full path "directory_path/file_name.txt". Only groups with two or more files are returned.

Output contract. Return a list of groups. Sort the paths inside each group, and sort the groups themselves, so the result is deterministic. File contents contain no spaces or parentheses.

Input encoding. Each test case is a JSON array [paths] holding the single list argument. The function returns the list of groups.

Input: paths = ["root/a 1.txt(abcd) 2.txt(efgh)","root/c 3.txt(abcd)","root/c/d 4.txt(efgh)","root 4.txt(efgh)"]

Output: [["root/4.txt","root/a/2.txt","root/c/d/4.txt"],["root/a/1.txt","root/c/3.txt"]]

Content efgh appears in three files and abcd in two; each becomes one group.

Input: paths = ["a 1.txt(x)","b 2.txt(y)"]

Output: []

No two files share content, so there are no duplicate groups.

Input: paths = ["root 1.txt(a) 2.txt(a) 3.txt(a)"]

Output: [["root/1.txt","root/2.txt","root/3.txt"]]

All three files hold the same content and form one group.

How this uses the pattern

Build a dictionary from content to the list of paths that hold it. Parse each entry into a directory and its files, split each file into name and content, and append the joined path under that content. Then keep only the buckets with more than one path.

Find Duplicate File in System: Group by Content

Python

Focus Mode

Loading...

OutputSubmissions

Run

Submit

Click "Run" to execute your code

Test Cases

Input: [["root/a 1.txt(abcd) 2.txt(efgh)","root/c 3.txt(abcd)","root/c/d 4.txt(efgh)","root 4.txt(efgh)"]]Expected: [["root/4.txt","root/a/2.txt","root/c/d/4.txt"],["root/a/1.txt","root/c/3.txt"]]

Input: [["root/a 1.txt(abcd) 2.txt(efgh)","root/c 3.txt(abcd)","root/c/d 4.txt(efgh)"]]Expected: [["root/a/1.txt","root/c/3.txt"],["root/a/2.txt","root/c/d/4.txt"]]

Input: [["a 1.txt(x)","b 2.txt(y)"]]Expected: []

Input: [["root 1.txt(a) 2.txt(a) 3.txt(a)"]]Expected: [["root/1.txt","root/2.txt","root/3.txt"]]

Input: [["root 1.txt(a)"]]Expected: []

Input: [["x 1.txt(z) 2.txt(z)"]]Expected: [["x/1.txt","x/2.txt"]]

Need a hint? (3 available)

The Dropbox angle

This is deduplication written as a coding problem, and it is the closest thing in this band to what Dropbox does in production. The block store hashes every chunk and stores identical ones once; here you group identical files by content. The trap most people hit is the parsing, not the grouping: the content sits inside parentheses glued to the file name, so a careless split loses the boundary. Get the tokenizing clean and the dictionary does the rest.

Take it further

The real-world turn: the files are large, so keying the map on raw content is expensive in memory and comparison. Key on a content hash instead, the exact move the block store makes, and verify byte-equality only when two hashes collide.

Show solution & walkthrough

2

Subdomain Visit Count: Roll Up a Namespace

MediumCommonly asked

Problem

A count-paired domain is a string "count domain", where count is the number of visits to domain. A domain like "discuss.leetcode.com" implies visits to itself and to each parent suffix: "leetcode.com" and "com". Given a list of count-paired domains, return the total visit count for every subdomain that appears, each formatted as "count subdomain".

Output contract. Sort the output strings so the result is deterministic.

Input encoding. Each test case is a JSON array [cpdomains] holding the single list argument. The function returns the list of "count subdomain" strings.

Input: cpdomains = ["9001 discuss.leetcode.com"]

Output: ["9001 com","9001 discuss.leetcode.com","9001 leetcode.com"]

The 9001 visits credit the full domain and each parent suffix.

Input: cpdomains = ["1 a.b.c","2 b.c"]

Output: ["1 a.b.c","3 b.c","3 c"]

b.c gets 1 from the first entry and 2 from the second; c gets both.

Input: cpdomains = ["5 a"]

Output: ["5 a"]

A single-fragment domain has no parents, so it credits only itself.

How this uses the pattern

For each entry, split the count from the domain, then split the domain on dots. Walk from each fragment to the end to form every suffix, and add the count into a map under each suffix. Format the map at the end.

Subdomain Visit Count: Roll Up a Namespace

Python

Focus Mode

Loading...

OutputSubmissions

Run

Submit

Click "Run" to execute your code

Test Cases

Input: [["9001 discuss.leetcode.com"]]Expected: ["9001 com","9001 discuss.leetcode.com","9001 leetcode.com"]

Input: [["900 google.mail.com","50 yahoo.com","1 intel.mail.com","5 wiki.org"]]Expected: ["1 intel.mail.com","5 org","5 wiki.org","50 yahoo.com","900 google.mail.com","901 mail.com","951 com"]

Input: [["1 a.b.c","2 b.c"]]Expected: ["1 a.b.c","3 b.c","3 c"]

Input: [["10 mail.com"]]Expected: ["10 com","10 mail.com"]

Input: [["1 a.com","1 b.com"]]Expected: ["1 a.com","1 b.com","2 com"]

Input: [["5 a"]]Expected: ["5 a"]

Need a hint? (3 available)

The Dropbox angle

This is a namespace rollup, and Dropbox lives in namespaces. A visit to a deep domain credits every parent suffix, exactly as a write inside a nested folder should update the byte total of every ancestor folder up to the shared-folder root. The metadata service answers "how big is this folder" from maintained rollups like this rather than by walking the subtree on every request. The graded catch is the suffix construction: build each parent by joining fragments from an index to the end, and accumulate into the map instead of looping twice.

Take it further

Swap dotted domains for slash-separated paths and the same idea rolls a write up every ancestor folder. A write to team/design/logo increments team/design and team too, which is how a folder tree keeps subtree totals ready to read.

Show solution & walkthrough

3

Longest Substring Without Repeating: Forward-Only Window

MediumCommonly asked

Problem

Given a string s, return the length of the longest contiguous substring that contains no repeated character.

Input encoding. Each test case is a JSON array [s] holding the single string argument. The function returns the length as an integer.

Input: s = "abcabcbb"

Output: 3

The longest clean run is "abc", of length 3.

Input: s = "bbbbb"

Output: 1

Every character repeats, so the best is a single "b".

Input: s = "pwwkew"

Output: 3

"wke" is the longest run with no repeat; "pwke" is not contiguous.

How this uses the pattern

Slide a window with a map of each character's last seen index. When the right edge sees a character already inside the window, jump the left edge just past its previous position. Track the largest window width.

Longest Substring Without Repeating: Forward-Only Window

Python

Focus Mode

Loading...

OutputSubmissions

Run

Submit

Click "Run" to execute your code

Test Cases

Input: ["abcabcbb"]Expected: 3

Input: ["bbbbb"]Expected: 1

Input: ["pwwkew"]Expected: 3

Input: [""]Expected: 0

Input: ["au"]Expected: 2

Input: ["dvdf"]Expected: 3

Input: ["abba"]Expected: 2

Need a hint? (3 available)

The Dropbox angle

A forward-only window, and the "forward-only" part is the Dropbox connection, so name it. Both edges only ever move right, so the scan reads each character exactly once and never rewinds. That is precisely how the sync engine walks a file's byte stream on its single control thread to decide chunk boundaries. The common bug is jumping the left edge to a stale index. Only advance it when the repeated character's last position is inside the current window; otherwise you shrink a window that was already clean.

Take it further

The frequent next ask relaxes "no repeats" to "at most K distinct characters." The window keeps a count per character and shrinks from the left whenever the number of distinct characters exceeds K, which is a live map size check rather than a last-seen jump.

Show solution & walkthrough