# Turn an Unlikely Project Around and Recover When AI Coding Falls Short Prepare two senior-level examples. First, describe a project that initially appeared impossible and how you made a credible outcome possible. Second, describe a time an AI coding tool could not produce the code or behavior you expected and how you diagnosed and recovered from the failure. ### Constraints & Assumptions - Use real examples for which you can explain your own technical and leadership decisions. - Do not treat working longer hours or repeatedly prompting the tool as the whole strategy. - Include evidence for the outcome and one lesson that changed later practice. - Protect confidential implementation details while remaining technically specific. ### Clarifying Questions to Ask - Should the first example emphasize delivery, organizational alignment, or technical feasibility? - For the AI example, is the interviewer most interested in code correctness, workflow design, or safe tool use? ### Part 1: Making the Impossible Possible Explain why the original plan appeared infeasible, what evidence changed the plan, which constraints you renegotiated, and how you controlled the remaining risk. #### What This Part Should Cover - Decomposition of the perceived impossibility into specific constraints and unknowns. - A high-leverage technical or coordination decision. - Explicit scope, deadline, or quality trade-offs agreed with stakeholders. - A measurable result and candid remaining limitations. ### Part 2: Recovering from an AI Coding Failure Explain the expected behavior, how the generated result failed, how you separated prompt/context problems from model limitations and repository issues, and how you completed and verified the work. #### What This Part Should Cover - Reproduction with deterministic tests and inspection of the actual diff or behavior. - Smaller hypotheses, better context boundaries, and manual engineering when appropriate. - Security, permission, and unintended-change checks. - A workflow improvement derived from the incident. ### What a Strong Answer Covers - Ownership, evidence, and decision quality rather than a heroic narrative. - Deep enough technical detail to show how uncertainty was reduced. - Clear limits on AI authority and independent verification of generated changes. - Results, trade-offs, and learning tied to later behavior. ### Follow-up Questions - What was the earliest signal that the original project plan would fail? - When did you decide another AI prompt was lower value than writing or debugging the code yourself? - What guardrail would have detected the AI failure sooner?