Problem statement
Design the class model and public APIs for an in-memory file system: the object graph that represents a tree of directories and files under a single root, plus the operations a shell or program calls to walk and mutate that tree. This is the storage kernel — no disk, no blocks — everything lives in process memory.
Operating context. One root ("/"), an arbitrarily deep tree of directories, and files that hold a mutable byte payload. Paths are POSIX-style, slash-separated, absolute or relative to a supplied working directory, and may contain "." and ".." segments to be resolved. The kernel must support create-file, open/read, write (overwrite and append), delete, make-directory, and list-directory, and must resolve a textual path to the node it names (or fail cleanly if a segment is missing or is not a directory). Many threads may call these operations concurrently on overlapping paths, so the design must stay consistent under interleaving. Leave room for two extensions the interviewer will push on: a permission check invoked before every operation, and symbolic links that point at another path and are followed during resolution.
Out of scope. On-disk persistence, blocks / inodes / an allocation layer, journaling and crash recovery, buffer caching and mmap, the shell / command parser and its I/O, user and group administration (assume an identity is handed to you), and network / distributed mounts. Model the in-process object graph and its APIs, not the OS around it.
What to produce. The class hierarchy (a common node abstraction with directory and file as the two concrete kinds, the tree that owns the root, a path/resolver seam, and the seams for permissions and links), the public API each class exposes, and the explicit state a node carries (name, parent link, children or byte content, metadata). Be explicit about: how directory and file share one node type via a composite so a directory holds children uniformly; how a path string is resolved segment by segment (including ".", "..", and a not-a-directory error); how create / read / write / delete / mkdir / ls are expressed against resolved nodes; how a permission check hooks in front of every operation without scattering if-checks everywhere; how a symlink node is followed during resolution without infinite loops; and how concurrent callers are kept from corrupting the tree.