## Question Tell me about a piece of code you wrote that you are proud of. Explain the problem, why the code is better than the obvious alternative, its API and invariants, how it is tested, and why maintainers can safely change it. ### Constraints & Assumptions - Choose code you personally wrote or substantially redesigned. - Pride must come from a defensible quality such as clarity, correctness, simplicity, or operability, not cleverness alone. - Be prepared to show or reconstruct a representative fragment without exposing proprietary code. - Include one limitation or later improvement. ### Clarifying Questions to Ask - Would you prefer production code, a library, or a tool? - Should I focus on design, tests, or an implementation detail? - May I sketch pseudocode for the core invariant? ```hint State the invariant The most convincing code story explains the property that every operation preserves and how tests make that property hard to break. ``` ### What a Strong Answer Covers - User and failure context for the code. - A small understandable API and explicit invariant. - Rejected complexity and readable implementation choices. - Tests for boundaries and failures, not coverage percentage alone. - Evidence of maintainability and an honest limitation. ### Follow-up Questions 1. Which line or abstraction is easiest to misuse? 2. What change would force a redesign? 3. How did code review alter the result? 4. What would a new maintainer need to know first?