Unix `find` Command

Phase 1: Requirements & Use Cases

Interviewer: "Design an object-oriented version of the Unix find command."

Candidate: "Before I model anything, let me clarify scope. The Unix find command traverses a directory tree and emits paths that satisfy one or more filter criteria. At a minimum I'm thinking: search by name, by extension, by file size, by modification time, by type (regular file vs. directory), and the ability to combine those filters with AND, OR, and NOT. Is that the right scope, or are there additional operations you want to cover?"

Interviewer: "That's the right scope. What else do you want to confirm?"

Candidate: "A few things. First — are we building a callable library API, a command-line parser, or both? Second — does this need to handle the real filesystem, or are we designing against an abstraction so it can be tested in memory? Third — do we need to support find -exec — executing an arbitrary command on each result? Fourth — should we respect find's -maxdepth flag? Fifth — does the traversal need to detect and break circular symbolic links, as the real find does?"

Interviewer: "Design a library API against a filesystem abstraction. Include -exec-style action execution and -maxdepth as Phase 6 extensions. Handle circular symlinks when you get there."

Candidate: "Perfect. The actors are: User (invokes the search, composes criteria, receives results), FileSystemTraverser (walks the directory tree via the filesystem abstraction), FileEntry (a value object representing a node in the tree — file or directory), and Criterion (the interface that each…