## Scenario You are given an existing codebase for a library catalog lookup and lending system. The assessment has five sequential phases: 1. Clarify the baseline product requirements with an AI product manager. 2. Implement the baseline with a coding assistant. You may use your own notes, but you may not paste the product manager's response verbatim into the coding assistant. 3. Fix a small metrics-related bug manually. AI assistance is prohibited in this phase, and the defect is caused by a metrics operation being placed in the wrong part of a function. 4. Clarify a more complex follow-up feature with the AI product manager. 5. Implement as much of that follow-up as possible under tight time pressure. The exact baseline requirements, follow-up requirements, repository layout, and metric semantics will be revealed inside the assessment. Do not invent them. Explain how you would obtain the missing facts, turn them into an implementation plan, make the manual fix safely, and keep a valid submission throughout the exercise. ### Constraints & Assumptions - Treat each phase's tool policy as a hard boundary. The coding assistant is available only when that phase permits it. - Ask the product manager a consolidated set of questions rather than spending the phase on one-question-at-a-time exchanges. - Preserve the meaning of the product manager's answers, but express implementation instructions in your own words. - Use the existing code and tests to determine the intended metric semantics. The prompt does not establish whether the metric counts attempts, successes, failures, or another event. - Prefer targeted automated checks over broad codebase exploration or lengthy manual testing when time is scarce. - Keep the latest known-good implementation submitted or checkpointed before taking on another slice of work. ### Clarifying Questions to Ask Before the timed phases begin, confirm the mechanics that affect your plan: - What ends a product-manager phase: an explicit acknowledgement that the requirements are complete, a fixed interaction limit, or both? - Does the note area persist across phases, and may it contain a structured summary of the product manager's answers? - Which build and test commands are authoritative for the existing repository? - Does each submission replace the prior checkpoint, and can a passing checkpoint be recovered if a later change is incomplete? - In each phase, which tools are allowed for editing, searching, testing, and asking for code changes? ### Part 1 — Clarify the Baseline Product Draft one consolidated message to the AI product manager. It should uncover enough information to implement the initial library lookup and lending behavior without assuming product rules that have not been stated. Cover users and permissions, search behavior, lending state transitions, frontend and backend responsibilities, failure cases, and acceptance tests. Explain how you would recognize that clarification is complete and how you would organize the answers for the next phase. ```hint Group questions by decision area Organize the message around catalog search, copy availability, lending rules, interfaces, error behavior, and testable acceptance criteria so related decisions can be answered together. ``` #### What This Part Should Cover - A single, well-organized product-manager message that asks concrete questions about this library system. - Explicit separation between required behavior, open decisions, non-goals, and testable outcomes. - Questions about both the user-visible flow and the data or service behavior needed to support it. - A clear stopping condition for the clarification phase and a compact note-taking format. ### Part 2 — Implement Without Copying the Product Transcript Describe how you would translate the answers into an original implementation brief for the coding assistant without pasting the product manager's response verbatim. Show how you would inspect only the relevant parts of the repository, divide the baseline into small changes, prompt the coding assistant, and verify its output despite tool latency. ```hint Build a decision record first Convert each product answer into a short requirement, its affected component, and an acceptance check before asking the coding assistant to edit code. ``` #### What This Part Should Cover - A traceable but independently worded requirements brief. - A repository plan tied to the confirmed catalog and lending flows rather than a request to rewrite the whole system. - Small implementation slices with a targeted test or observable check for each slice. - Review of generated changes for invented requirements, excessive scope, broken interfaces, and unrelated edits. ### Part 3 — Repair the Metrics Bug Manually You may search and edit the repository, but you may not use an AI coding tool. Explain how you would locate the buggy function by searching for the relevant metrics code, infer where the metrics operation belongs, make the smallest safe placement change, and validate it. Your answer must account for the fact that the prompt does not say what the metric is intended to count. ```hint Define the event before moving the call Use the metric name, neighboring branches, call sites, and tests to decide whether it represents an attempt, success, failure, or exactly-once completion event. ``` #### What This Part Should Cover - A fast search-and-trace method that does not depend on AI assistance. - An invariant for when the metric should and should not be emitted. - A minimal code-placement change that preserves the function's business behavior. - Targeted checks for correct branch coverage, correct call count, and unchanged error handling. ### Part 4 — Clarify the Follow-up Feature The product manager now introduces a more complex feature, but its exact rules are not included here. Draft a second consolidated message that focuses on the delta from the baseline system. Ask about the new user goal, affected catalog and lending flows, data and interface changes, compatibility with existing behavior, edge cases, and acceptance tests. Explain how you would prevent ambiguous answers from turning into guessed implementation details. ```hint Ask about the delta Anchor every question to what changes, what remains unchanged, and how the new behavior interacts with the baseline state transitions. ``` #### What This Part Should Cover - Questions that distinguish the follow-up from the already implemented baseline. - Specific coverage of permissions, state transitions, persistence, API or UI effects, failures, and backward compatibility. - A method for recording unresolved decisions and obtaining explicit confirmation instead of guessing. - Prioritized acceptance criteria that can guide an incremental implementation. ### Part 5 — Implement Incrementally Under Time Pressure Give a concrete execution and submission strategy for the follow-up phase. Assume coding-assistant edits and test runs can be slow. Explain how you would choose the smallest valuable vertical slices, protect a passing checkpoint, decide when to submit, and handle an unfinished final slice when time expires. ```hint Optimize for the last green checkpoint A partially complete feature is less useful if it replaces the only version known to build and pass the relevant tests. ``` #### What This Part Should Cover - A prioritized sequence of independently verifiable slices derived from the confirmed follow-up requirements. - Submission or checkpointing after each stable increment, not only at the end. - Focused prompts, narrow repository context, and targeted tests to reduce tool latency. - A cutoff rule that preserves the last passing version and clearly omits lower-priority behavior rather than leaving broken code. ### What a Strong Answer Covers - Maintains a clean boundary between product facts, candidate assumptions, and implementation decisions across all five phases. - Uses AI tools only where permitted and preserves independent reasoning for requirements translation, code review, and manual debugging. - Connects every confirmed behavior to a code area and an acceptance check without claiming unseen product or repository details. - Balances speed with correctness through consolidated clarification, small changes, targeted validation, and frequent valid checkpoints. - Recognizes that the correct metrics placement depends on the event being measured rather than on a universally correct line position. ### Follow-up Questions 1. What would you do if the product manager's answer conflicts with an existing test or interface in the repository? 2. How would you respond if the coding assistant implements an unstated lending rule that happens to make the visible tests pass? 3. What evidence would convince you that the metrics move is correct when there is no dedicated test for that metric? 4. If only one follow-up slice can be completed, how would you choose it and communicate the intentionally omitted behavior?