The round is three graded parts, handed over one at a time. The interviewer supplies the test cases — you do not write them — and runs them against your implementation before moving on to the next part.
Implement an in-memory Unix-style file system. Reports describe it as LeetCode 588 'lightly modified' and recommend backing it with a tree/trie of path nodes plus your own path parsing.
Part 1 — mkdir(), touch(), ls()
Create a directory, create an empty file, and list what a path contains.
Part 2 — rm(), rmdir()
Remove a file, and remove an empty directory. The two are not interchangeable: rm must refuse a directory, and rmdir must refuse one that still has children.
Part 3 — cd()
Change the working directory, so later commands resolve relative paths and .. against it rather than against /.
Common variant — raw command lines
Instead of calling the methods directly, you are fed command strings to tokenize, dispatch, and execute against the same tree:
mkdir /a
touch /a/f.txt
ls /a
One report also lists reading, writing, and searching. No report records any starting code, so expect to propose the API shape yourself.
Candidates consistently report that the design is not exotic. What fails people is writing it from scratch and debugging one stubborn edge case inside the time box, with an interviewer who offers almost no hints.
A common variant hands you raw command-line strings to parse and execute rather than calling methods directly.
Support cd and relative paths, so subsequent commands resolve against a current working directory.
Should mkdir behave like 'mkdir' (parent must exist) or 'mkdir -p' (create intermediate directories)?
Interviewer hints: The interviewer provides concrete test cases and runs them against the implementation — passing or failing those test cases appears to be the primary pass/fail signal.; The interviewer (described as offering almost no hints or interaction) largely watches silently even when the candidate is stuck on a bug, so candidates should not expect to be guided out of debugging holes.
What passers do: Used a trie/tree node structure as the core data model from the start, making traversal and path-parsing straightforward for all subsequent parts.; Candidates who completed the main interfaces and walked through the main flow with the interviewer fared better, even if a minor bug remained.
Common mistakes: conflating files and directories (ls/rm/rmdir behave differently on each); rmdir silently succeeding on a non-empty directory; path parsing that ignores '.', '..', trailing slashes, or absolute-vs-relative. Approach: build and unit-test the path resolver first so a bug is localized to one small function.
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 8 Perplexity questions, refreshed monthly from new candidate reports.