In-Memory File System

What's being tested

This tests hierarchical data modeling with a trie/tree of directories and files, plus robust path parsing and name-collision handling. Interviewers are looking for clean object design, edge-case discipline, and ability to reason about `mkdir`, `ls`, `addContentToFile`, `readContentFromFile`, capacity limits, and duplicate names.

Patterns & templates

• Trie/tree node model — each `Node` stores `children: Map[str, Node]`, `isFile`, optional `content`, metadata, and size; operations are O(path components).

• Path normalization — split on /, ignore empty components, handle root /; avoid bugs from trailing slashes like /a/b/.

• Directory traversal helper — implement `getNode(path, create=False)` to centralize validation, auto-creation, and missing-path behavior.

• Lexicographic listing — `ls(path)` returns [filename] for files or sorted child names for directories; sorting costs O(k log k).

• Content accounting — for constrained systems, track total bytes and per-file size deltas before appending; reject writes that exceed capacity.

• Duplicate naming policy — OS-style collisions often require generating `name(1)`, `name(2)`; maintain counters or scan siblings carefully.

• Complexity explanation — use d = path depth, k = directory children, c = content length; traversal O(d), append/read affected by c.

Common pitfalls

Pitfall: Treating files and directories as separate maps makes traversal and collision handling harder than a unified `Node` abstraction.

Pitfall: Forgetting that `ls("/a/file.txt")` should usually return only ["file.txt"], not file content or children.

Pitfall: Capacity checks must account for append delta, not total rewritten content unless the API replaces file contents.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.