Implement a Merkle tree over the contents of a cloned repository. The tree should let a client and server compare repository state efficiently by exchanging hashes rather than every file. Describe the data model, construction algorithm, update path, and the client/server protocol you would implement in a one-hour technical screen. ### Constraints & Assumptions - Files can be represented by normalized paths and byte contents. - A leaf hash is derived from one file; internal hashes are derived from child hashes. - The repository can fit in memory for the first version. - The unknown second part of the original prompt is out of scope. ### Clarifying Questions to Ask - Should directory names affect internal hashes, or only file paths and file contents? - Do we need incremental updates after one file changes? - Should the protocol identify changed files, missing files, or both? - Do symbolic links, ignored files, or binary files need special handling? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would you handle a very large repository? - How would the protocol resume after interruption? - What would change if files can be renamed? - How would you test deterministic hashing across platforms?