File System

Phase 1: Requirements & Use Cases

Interviewer: "Design an in-memory file system."

Candidate: "Sure. Let me confirm scope before jumping to classes. I'm imagining a hierarchical file system — like a Unix-style tree — with files and directories, both reachable by absolute paths. Core operations would be: create and delete files and directories, read and write file contents, navigate the tree, and search for entries by name or predicate. Does that match what you had in mind?"

Interviewer: "Yes. What clarifying questions do you have?"

Candidate: "A few. First — do we need symbolic links, or just regular files and directories? I'll design with symlinks in scope since they're a frequent follow-up. Second — do we need a permissions model? I'll include read/write/execute bits per entry. Third — is this purely in-memory, or do we need to serialize to disk? I'll design for in-memory, but the class structure should make persistence pluggable. Fourth — do we need multiple users and user-owned files, or just permission bits on entries?"

Interviewer: "Include symlinks. Include a basic permissions model but not multi-user ownership — a single owner per entry is enough. In-memory only. What actors interact with this system?"

Candidate: "Two primary actors: a User (creates, reads, writes, deletes entries, and navigates the tree) and the FileSystem itself (resolves paths, enforces permissions, maintains the root). A third implicit actor is any traversal or search client — something like grep — that walks the tree reading entries. I'll design the traversal interface so those clients don't need to know whether a node…