## Debug Feature Updates in a Laptop Management CLI You are debugging a command-line laptop management system. Each laptop belongs to one or more users and has a set of attached hardware features such as earbuds, a mouse, or a keyboard. A simple flow works: list a user's laptops, select a first laptop with no features, list its empty feature set, and update it interactively. A second flow fails: select a different laptop that already has four features, list them, then invoke the update command with the first laptop's ID. The explicit command argument is authoritative, so the update screen should preselect zero features for that first laptop. Instead it incorrectly marks one feature; submitting two feature choices exits with status 1. The implementation is available during the interview, but it is not reproduced here. Give a disciplined debugging plan and explain the code and state invariants you would inspect. Do not claim one exact root cause without evidence from the implementation. ### Part 1 — Reproduce and Minimize the Failure Turn the two command sequences into a small deterministic test. Identify the first observable state that differs from the command's intended target. #### What This Part Should Cover - Captured arguments, selected-laptop state, displayed values, input, exit status, and logs. - A minimal sequence that distinguishes selected state from explicit command target. - Zero expected preselected features because the explicitly named first laptop is featureless. - A control case for updating the currently selected laptop. - No reliance on clicking a generic run action when the CLI must be exercised in a terminal. ```hint Compare two identities at every step Record both the laptop named by the update command and any globally selected laptop before tracing the feature list. ``` ### Part 2 — Trace Read and Write State Follow the command from parsing through feature lookup, checkbox rendering, submitted-input parsing, validation, and persistence. State the invariants that should hold at each boundary. #### What This Part Should Cover - One authoritative laptop ID propagated through the operation. - Separation of the global feature catalog from a laptop's selected features. - The explicit update argument taking precedence over the previously selected laptop. - Consistent feature identity rather than display-position assumptions. - Transactional update behavior when validation fails. ```hint Follow data, not nearby code The suspicious line is the first place where the target ID or selected-feature set changes unexpectedly, not necessarily the line that throws the final error. ``` ### Part 3 — Repair and Verify Safely Describe the smallest evidence-backed patch once the cause is confirmed, and design regression tests for empty features, several features, a different selected laptop, invalid input, and repeated updates. #### What This Part Should Cover - A failing test before the patch and the same test passing afterward. - The first laptop receiving the submitted feature set while the four-feature laptop remains unchanged. - A clear error result without partial mutation. - Logs or errors that retain useful context without exposing sensitive user data. ```hint Assert both sides of the update A regression test should verify the intended laptop changed and the previously selected laptop did not. ``` ### What a Strong Answer Covers - Reproduces the observed command interaction before theorizing. - Tests the likely confusion between explicit target, selected state, catalog, and existing selection. - Treats the exit status as a symptom to trace rather than swallowing it broadly. - Refuses to invent an exact patch when the relevant source code is absent. ### Follow-up Questions 1. What telemetry would make this failure diagnosable without logging user names? 2. When is catching an exception appropriate, and when would it hide the bug? 3. How would you prevent two feature updates from overwriting each other? 4. Which test would catch a feature represented by value in one layer and by index in another?