Back

In-Memory File System

Also reported as In-Memory Unix File System · LeetCode 588 Design In-Memory File System

Phone ScreenPhone ScreenLast reported September 2026Medium Frequency

Problem Overview

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

  • Parts 4 and 5 exist, according to the September report, but no report describes them. A commenter asked whether Part 4 is something like mv or cp; no answer is recorded.
  • One July report was fed raw command lines to read, parse and execute instead of method calls, and some of its provided test cases did not pass.
  • One June report describes creating, reading, writing, finding and listing directories and files.

Follow-up Arc

Interviewers escalate through these phases. The order varies, but most candidates see at least one from each bucket.
Trade-off discussion · 3
Trade-off discussion

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.

What Reports Emphasize

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.

Practice

Write your own against 11 test cases, or read the worked solution — approach, complexity, and code that runs.
Perplexity · Phone Screen · Reported 6× across candidate reports
Is this helpful?