Leadership Questions: Goal Found Wrong Midway, Tight Deadline, Handoff, Beyond-Scope Work

Two rounds of a new-grad software engineer loop each opened with two questions based on Amazon's Leadership Principles before the technical part. Prepare a story-based answer for each of the four prompts below. The first two drew many follow-up questions, so expect to be asked for details behind every decision. ### Clarifying Questions - Does "the goal was wrong" cover requirements that the customer changed, or only a goal that you or your team discovered to be mistaken? - For the deadline story, is a case where you cut scope to ship on time acceptable, or should the full scope have shipped? - May the handoff story be about leaving at the end of an internship, or should it be a handoff to a teammate while you stayed on the team? - For the problem outside your responsibilities, does it still count if your manager later asked you to own it? ### Part 1 — The goal turns out to be wrong halfway through Tell me about a time you were partway through a project and discovered that its goal was wrong. What did you do? ```hint Evidence first Think about what exactly told you the goal was wrong, and whom you had to convince before changing course. ``` #### What This Part Should Cover - How the problem with the goal was detected, with concrete evidence - How the decision to change course was raised and agreed, and what work was salvaged - The outcome compared with finishing the original plan ### Part 2 — Delivering under a tight deadline Tell me about a time you had to deliver under a tight deadline. How did you make sure it shipped? ```hint What gave way Ask what you traded to meet the date (scope, polish, process) and how you protected the parts that could not be traded. ``` #### What This Part Should Cover - How the work was prioritized, and what was cut or deferred and why - How quality and risk were controlled under time pressure - The delivered result and what happened to the deferred work ### Part 3 — Handing off a project you owned How did you hand over a project you were responsible for to someone else? ```hint The receiver's first week Picture the first week of the person taking over: what would they need that is not written down anywhere? ``` #### What This Part Should Cover - What was transferred: documentation, open issues, operational knowledge and stakeholder relationships - How you verified that the new owner could run it without you - What happened after the handoff ### Part 4 — Solving a problem outside your responsibilities Tell me about a time you proactively solved a problem that was not your responsibility. ```hint Why you Be ready to explain why the problem was not yours, why nobody else was fixing it, and how you avoided stepping on its owner. ``` #### What This Part Should Cover - How the problem was noticed and why it mattered to customers or the team - How the actual owners were involved - The measurable result and whether the fix lasted ### What a Strong Answer Covers - Four real, distinct stories told in a situation, task, action and result structure, with "I" clearly separated from "we" - Decisions explained with their reasoning and the alternatives that were rejected - Quantified results and an honest account of what went wrong - Answers that hold up under several layers of follow-up questions - A lesson from each story that changed later behavior ### Follow-up Questions - In the wrong-goal story, what would you have done if your manager had told you to keep going as planned? - What exactly did you cut to meet the deadline, and did anyone object? - After the handoff, what was the first question the new owner had to ask you, and what does that say about your documentation? - How did the owner of the problem you fixed react, and would you approach it the same way again?