class FileSystem:
An in-memory Unix-style file system, from six first-hand reports between May and September 2026. Four of the posts' titles call the round a phone screen and one body calls it a coding round; none mentions an onsite. Two reports name LeetCode 588; a third says a LeetCode problem is similar but this one was reworked.
One report lists three parts: mkdir, touch and ls; then rm and rmdir; then cd. Another lists the first two. The September report says the round has five parts, that a test file and the base class skeleton are given, and that the candidate finished Part 4 with a few minutes left and was not shown Part 5. No report says what Parts 4 and 5 ask, so this page grades Parts 1 to 3.
What the tests call (our setup — ask your interviewer). The real skeleton was never posted, so the class name, the signatures and the shape of what ls returns are ours. The method names are reported.
class FileSystem:
def __init__(self): ... # an empty file system
def mkdir(self, path: str) -> None: ... # Part 1
def touch(self, path: str) -> None: ... # Part 1
def ls(self, path: str) -> list[str]: ... # Part 1
def rm(self, path: str) -> None: ... # Part 2
def rmdir(self, path: str) -> None: ... # Part 2
def cd(self, path: str) -> None: ... # Part 3
ls returns the names of the entries directly inside a directory, as a list or a whitespace-separated string, in any order. The tests also accept an ls that prints the names instead of returning them, a trailing '/' on directory names, or full paths. Anything else your methods print is ignored. The tests only create entries inside directories that already exist, and the only error case they make is the one in Part 2.
Part 1 — Create and list
mkdir(path) creates a directory, touch(path) creates an empty file, and ls(path) lists what a directory contains. Paths are absolute, such as /a/b. The same name under different parents gives separate entries, and so do names that share a prefix, such as /a and /ab. Each new FileSystem() starts empty.
Not graded — Parts 4 and 5, and other reported forms
Standard explanation — no candidate report records what the interviewer accepted here.
Our approach: resolve the parent directory and delete the last name from its children. rm removes a file; rmdir removes a directory only when it is empty and leaves one with entries in place (the Unix meaning; the reports name the two commands and nothing more). One of the candidates who reported this part ended on a small bug they could not debug and was rejected two days later; the post does not say where the bug was.
Standard explanation — no candidate report records what the interviewer accepted here.
Maintain a 'current directory' pointer (trie node or path string); for absolute paths start from root, for relative paths start from current node; traverse the trie accordingly. '..' moves to the parent; a parent pointer on each node makes it one step.
One July report was fed raw command lines to read, parse and execute, used trie nodes underneath, and had some of the provided test cases fail; it does not say why. The example lines above are ours. Our approach: split each line into a command and its path and dispatch to the same methods, so the parsing stays a thin layer over the tree.
From candidate reports: six first-hand reports, May to September 2026. Four of the posts' titles call the round a phone screen, one body calls it a coding round, and none mentions an onsite. Two reports name LeetCode 588 and a third says a LeetCode problem is similar but this one was reworked. One report lists the parts as mkdir, touch and ls; then rm and rmdir; then cd. Another lists the first two.
The September report says the round has five parts and that a test file and the base class skeleton are given. The candidate finished Part 4 with a few minutes left and was not shown Part 5, wrote a lot of code for many commands, and found and fixed a few of their own bugs. The post does not state an outcome. Another report says test cases are provided and you need not write your own.
Outcomes stated in the posts: two rejections, one two days after the round and one the next day, each after the candidate could not find one bug in time; one of them had basically finished the code. A third candidate expected a fail after some provided test cases did not pass. The other three posts state no outcome. One rejected candidate says the interviewer gave almost no hints and mostly watched, and calls the problem itself reasonable.
Not captured: the real test file, the class skeleton, and what Parts 4 and 5 ask. The tests on this page are ours, built from the reported command names and their Unix meaning.
Also reported as In-Memory Unix File System · LeetCode 588 Design In-Memory File System
An in-memory Unix-style file system, from six first-hand reports between May and September 2026. Four of the posts' titles call the round a phone screen and one body calls it a coding round; none mentions an onsite. Two reports name LeetCode 588; a third says a LeetCode problem is similar but this one was reworked.
One report lists three parts: mkdir, touch and ls; then rm and rmdir; then cd. Another lists the first two. The September report says the round has five parts, that a test file and the base class skeleton are given, and that the candidate finished Part 4 with a few minutes left and was not shown Part 5. No report says what Parts 4 and 5 ask, so this page grades Parts 1 to 3.
What the tests call (our setup — ask your interviewer). The real skeleton was never posted, so the class name, the signatures and the shape of what ls returns are ours. The method names are reported.
class FileSystem:
def __init__(self): ... # an empty file system
def mkdir(self, path: str) -> None: ... # Part 1
def touch(self, path: str) -> None: ... # Part 1
def ls(self, path: str) -> list[str]: ... # Part 1
def rm(self, path: str) -> None: ... # Part 2
def rmdir(self, path: str) -> None: ... # Part 2
def cd(self, path: str) -> None: ... # Part 3
ls returns the names of the entries directly inside a directory, as a list or a whitespace-separated string, in any order. The tests also accept an ls that prints the names instead of returning them, a trailing '/' on directory names, or full paths. Anything else your methods print is ignored. The tests only create entries inside directories that already exist, and the only error case they make is the one in Part 2.
Part 1 — Create and list
mkdir(path) creates a directory, touch(path) creates an empty file, and ls(path) lists what a directory contains. Paths are absolute, such as /a/b. The same name under different parents gives separate entries, and so do names that share a prefix, such as /a and /ab. Each new FileSystem() starts empty.
Part 2 — Remove
rm(path) removes a file and leaves its siblings. For rmdir(path): rmdir removes an empty directory; on one that still has entries it leaves it in place (signal it however you like). This is the Unix meaning; no report states it.
Part 3 — Change directory
cd(path) changes the working directory, which starts at the root. After that, a path that does not start with '/' resolves against the working directory in every command: mkdir, touch, ls, rm, rmdir and cd itself. '..' moves to the parent directory, and cd with the path / returns to the root. That is the Unix meaning (our setup); the report names cd and nothing more.
Not graded — Parts 4 and 5, and other reported forms
Part 2 — implement rm() and rmdir() on the same class (two reports list this part).
Part 3 — implement cd() (one report lists it as the third part).
Parts 4 and 5 — the September report says the round has five parts; no report describes the last two. A commenter asked whether Part 4 is something like mv or cp; no answer is recorded.
Interviewer hints: None recorded beyond the setup: a test file and a base class skeleton are given (one report), and another report says test cases are provided so you need not write your own. One rejected candidate says the interviewer gave almost no hints and mostly watched while they explained their debugging.
Reports recommend: a tree or trie of path nodes. Four reports used or recommend one, and one adds practising path parsing.
How rounds ended: two candidates each ended on one bug they could not find in time and were rejected, one of them with the code basically finished. A third expected a fail after some provided test cases did not pass. The September candidate finished four of five parts and stresses volume: a lot of code and many commands, with a few of their own bugs found and fixed. That post states no outcome.
Edge cases to settle (our list, not reported): files versus directories in ls, rm and rmdir; rmdir on a directory that still has entries; '.', '..', trailing and double slashes; relative versus absolute paths once cd exists. Approach (ours): write one path resolver first and test it before the commands, so a bug stays in one small function.