Work through a snapshot-set iterator and then explain how you would clarify a separate durable-writer exercise whose detailed contract has not been preserved. ### Part 1: Snapshot Set Iterator Design a mutable set with `add`, `remove`, and `iterator`. An iterator must enumerate exactly the elements present at the instant the iterator is created. Later additions and removals must not change that iterator's result. Each snapshot must return every captured element once, in a documented deterministic order. #### What This Part Should Cover - Snapshot semantics and iterator lifetime - A simple copy-on-iterator design - Alternatives such as versions, copy-on-write, or persistent structures - Complexity and concurrent-access assumptions ### Part 2: Durable Writer Requirement Discovery The only surviving description of a second exercise is "durable data writer." Before proposing code, list the questions needed to establish its contract. Organize them around acknowledgment, crash behavior, ordering, concurrency, recovery, and storage ownership. Explain how different answers would change the design. #### What This Part Should Cover - What "durable" means at the acknowledgment boundary - Process crash versus machine or device failure - Append, overwrite, batching, and ordering semantics - Idempotency and recovery format - Why guessing a missing contract would be unsafe ### What a Strong Answer Covers A strong answer gives a correct simple snapshot implementation before optimizing it and treats the incomplete durable-writer prompt as a requirements problem rather than inventing hidden APIs. ### Follow-up Questions - How would you reclaim old snapshot versions? - What changes when writers and iterators run concurrently? - Which durability guarantees can an application make without filesystem and hardware assumptions?