Implement a simple file system supporting two core operations: 1.
Implement a simple file system supporting two core operations:
addFile(String path) — given a full path string like "path/to/somewhere/file.txt", store the file at that location in the hierarchy.getFile(String path) — given a path, return the file or folder at that location (e.g., input "path/to/somewhere" returns "file.txt"; input "path/to" returns the folder "somewhere").Also support createFolder(path) and listFiles(folderPath) operations (list all items under a given directory).
Constraints and follow-ups typically include:
A.txt already exists in the same directory and another A.txt is added, rename it to A(1).txt. If A(1).txt also exists, name it A(2).txt, etc. Edge case: adding file.txt, file.txt, then file(1).txt should yield file.txt, file(1).txt, file(1)(1).txt.How would you handle duplicate file names in the same directory?
Add a constraint: each directory can hold at most 5 items (files and folders combined). How do you enforce this?
How would you determine if two files have identical content?
How would you implement this file system in a production environment?
| Approach | Notes |
|---|---|
| Flat HashMap with full-path keys | Simpler to implement for basic add/get; avoids building a tree. However, listing directory contents or enforcing per-directory constraints (max 5 items) requires scanning all keys with a given prefix, which is less efficient and harder to maintain. |
| Trie (explicit tree nodes) | Naturally models the hierarchy; makes listing children and enforcing per-level constraints straightforward. Slightly more complex to implement than a flat map but scales better for deep path queries and listing operations. |
Common mistakes: Not anticipating the tricky duplicate-name test case where the counter wraps the whole filename — e.g., treating file(1).txt as already-taken and not producing file(1)(1).txt.; Candidates who failed did not know what the production follow-up was asking and gave unfocused answers about storage structures and NoSQL without a clear direction.; One candidate completed every coding part correctly but was inexplicably rejected due to a disengaged interviewer, suggesting non-technical factors can also sink outcomes.
Interviewer hints: The interviewer ran specific test cases without announcing them in advance, including the three-add duplicate collision case, then asked 'do you know what these test cases are doing?'; One interviewer explicitly said the tricky part is handling duplicate file names — A becomes A(1) on re-insert.; The production follow-up ('how would you implement this in production?') was asked verbally without requiring code; the interviewer seemed to want a high-level architectural answer but was not clear about what specifically they wanted.
What passers do: Candidates who prepared from prior reports and knew the duplicate-filename test case (add(file.txt), add(file.txt), add(file(1).txt) → file.txt, file(1).txt, file(1)(1).txt) handled it quickly and correctly.; Using a Trie (prefix tree) structure was specifically mentioned as a clean way to implement the directory hierarchy; candidates who used it moved through the problem fast.; Answering the 'identical file content' follow-up with file hashing (SHA-256 / MD5) led to passing the phone screen.; Finishing the core coding quickly (one candidate finished all parts in 45 minutes) left time for discussion rather than pressure.
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 9 Harvey AI questions, refreshed monthly from new candidate reports.