You are completing an engineering **Work Simulation** assessment for an Amazon **Software Engineer (SDE)** role. The assessment presents realistic on-the-job scenarios. For each scenario you are shown several proposed responses, and you must rate **each** response on a 1-to-5 scale, where **1 = least effective / least valuable** and **5 = most effective / most valuable**. Ratings are **not** rankings: multiple responses in a scenario can share the same score, and you do not have to use every number. Judge each response on its own merits against what a strong Amazon engineer would actually do — weighing **ownership, customer impact, technical quality, communication, collaboration, escalation, and deadline risk**. The assessment is organized into three modules. Within each module, rate every response in every scenario. ```hint How responses are scored This is a Situational Judgement Test (SJT), not a trivia quiz. Each response is rated against a behavioral rubric, not against a single "correct" answer. Map each response to the dimensions in the prompt — does it take ownership of the next step, protect the customer, preserve engineering quality, and involve the *right* person at the *right* time? ``` ```hint The Amazon lens The dimensions the assessment rewards line up with Amazon's Leadership Principles, often in tension with one another: **Ownership** (who is holding the next concrete step?), **Earn Trust** (is the message transparent and specific, and is feedback — especially senior feedback — being taken seriously?), **Insist on the Highest Standards** (is necessary testing or a known customer-impacting bug being treated as negotiable?), **Bias for Action** (is the response acting and escalating on a sensible timeline?), and **Dive Deep** (does the engineer understand the tradeoff themselves?). When you evaluate a response, ask which of these principles it serves and which it sacrifices — that tension is what separates the scores. ``` ```hint Reading each response carefully Wording can be misleading: a response can sound collaborative or polite while quietly doing something the rubric weighs differently — for example handing the decision or the code to someone else, choosing a wide audience for what is really a private matter, or pushing the action out in time. Before you score, restate what the response *actually commits you to doing, when, and with whom*, then weigh that against the dimensions in the prompt rather than against how agreeable it sounds. ``` ### Constraints & Assumptions - You are an individual contributor SDE; the other named people are teammates, senior engineers, team leads, or product stakeholders (e.g., Matthew and Mai are leads; Ryan and Becky are senior/reviewing engineers; Amber owns quality/testing; Monique pushes for speed). - Rate on a **1-5 integer scale**; ties are allowed and not every value must be used. - Where the prompt says "first" or "immediate" message/action, evaluate the response *as the opening move*, not as the entire eventual plan. - The scenarios involve real launch deadlines, customer-facing features (redirects, in-game purchases), and code-review gates. Customer impact and launch quality are first-class concerns. ### Clarifying Questions to Ask Before answering this kind of assessment, a strong candidate confirms the rules of engagement: 1. Are the ratings independent per response, or must I rank-order them (i.e., are ties allowed)? 2. For "first message" / "immediate reply" scenarios, am I rating the response as the *opening move* or as a complete plan? 3. What is the seniority and role of each named person (lead, senior engineer, quality owner, product), and what authority do I have to block a launch or approval? 4. How customer-facing and reversible is the feature in question (e.g., a purchase flow vs. an internal tool)? 5. Is there a hard, immovable deadline, or is the deadline a target that can be renegotiated? 6. Does the team have existing tooling (CI gates, required code-review approvals) that the responses can lean on? --- ## Module 1 — Project Alert: API design, feedback, and debugging You proposed an API implementation for "Project Alert." Across these scenarios, Ryan, Matthew, Becky, and Claire give feedback, ask for status, or request help. ### Part 1.1 — Ryan's code review feedback You proposed an API implementation. Ryan reviews your approach and suggests a **more complex** design that he believes will provide more long-term value. After thanking Ryan for the feedback, rate these possible replies: - **A.** Meet with Ryan to discuss his concerns and recommendations before deciding whether to revise your approach. - **B.** Set up a meeting with Ryan *and the rest of the Project Alert team* so the group can decide the approach. - **C.** Tell Ryan that the solution needs to be long-term and invite him to make whatever code changes he thinks are best. ```hint Each reply distributes the *decision* and the *ownership of the code* differently: one keeps both with you while you understand the tradeoff, one moves the decision to a larger group, and one moves the work itself to the reviewer. Weigh how engaging with the feedback trades off against who ends up owning the code. ``` #### What This Part Should Cover - **Engaging the feedback** vs. deflecting or rubber-stamping it — does the reply build genuine shared understanding of Ryan's tradeoff? - **Where ownership of the code lands** after the reply — does it stay with you, move to a group, or get handed to the reviewer? - **Right-sizing the forum** — one-on-one alignment vs. convening the whole team as a *first* move. ### Part 1.2 — Matthew asks for a progress update You have worked on Ryan's suggested code changes for two days and expected to be ready for final review. You just discovered an unexpected test failure caused by a **race condition**. Matthew asks for an update. Rate these as the **immediate first message**: - **A.** Say that you found a race condition, ask for Matthew's advice troubleshooting it, and promise to send additional details shortly. - **B.** Say that you found an error and will set up a meeting with Ryan because Ryan suggested the revised approach. - **C.** Say that you found a race condition, will keep working on it, and may need the team's help at the team meeting **in two days**. - **D.** Say that the suggested code modifications caused an issue and you will submit your **original** code for review so the launch is not delayed. - **E.** Say that you found a race condition, need more troubleshooting time, and **will not** meet the final review deadline. ```hint Score on three axes at once: transparency/specificity, ownership of the next step, and timeliness. Notice how each reply handles the timeline (act now vs. wait), whether it includes a concrete next step, and whether it keeps the new design or quietly walks it back — and weigh those against an honest-but-incomplete message. ``` #### What This Part Should Cover - **Transparency and specificity** — naming the actual problem (the race condition) vs. a vague "error" or hiding it. - **Ownership and a concrete next step** — does the message commit *you* to acting now, or does it defer, wait, or push the problem onto someone else? - **Timeliness vs. an honest-but-incomplete update** — acting immediately beats a two-day wait or a bare deadline-miss with no mitigation. - **Preserving the agreed design** vs. quietly reverting to the original code to protect the date. ### Part 1.3 — Becky has concerns about your approach Matthew asks Becky, a senior engineer, to help troubleshoot. Becky finds that a **global variable** is causing the race condition, but she is also concerned about your **overall approach** and asks to discuss it today. Rate these replies: - **A.** Agree to discuss and set up a meeting with Matthew, Becky, and yourself so the group can align. - **B.** Thank Becky for raising the concern and ask her to tell you what approach to implement. - **C.** Thank Becky for the race-condition advice, say you will make that fix, and publish the code without further changes. - **D.** Thank Becky for the help but say the approach has already been thoroughly reviewed and does not need another review. - **E.** Say you do not think the approach should change, but you will ask Matthew to confirm. ```hint A senior engineer raising a design concern is a signal about how to respond. Contrast replies that genuinely engage and align on the concern with ones that defer to her judgment wholesale, fix only the symptom while leaving the concern unaddressed, dismiss the concern, or route around her to a third party. ``` #### What This Part Should Cover - **Taking senior feedback seriously** without either dismissing it or blindly outsourcing the decision to her. - **Addressing the design concern, not just the symptom** — the global-variable fix is necessary but doesn't resolve what Becky actually raised. - **Co-owning the decision** — engaging and aligning vs. routing around her to the lead to validate a position you've already closed. ### Part 1.4 — Claire needs help with your API Claire is getting errors when calling the API you developed. She already tried your suggestions, but the same error keeps happening. She needs help before **tomorrow morning's status meeting**. Rate these replies: - **A.** Ask whether she implemented your suggestions and tell her to work through them first if she has not. - **B.** Recommend asking Matthew for help because your troubleshooting did not fix the issue. - **C.** Offer an hour later today to help, and agree to involve Matthew if you cannot solve it together. - **D.** Say you are busy, ask her to send her code, and say you will revise it later today. - **E.** Point her to your completed API documentation and ask her to follow up only if the error persists after reading it. ```hint She already tried your suggestions and the clock is ticking before tomorrow's meeting. Weigh how concretely each reply commits *your* time to the problem, and what it does about a path forward if the two of you can't crack it — against replies that re-point her at things she's already done or push the work to "later." ``` #### What This Part Should Cover - **Concrete commitment of your time** to an urgent, recurring error in *your* API — a specific slot today vs. "later" or a doc/suggestion she's already exhausted. - **A defined escalation path** if you two can't solve it (involving the lead) before the deadline. - **Not re-pointing her at work she's already done** or prematurely handing the problem off. --- ## Module 2 — Sound Traveller: tracking platform and redirect button You are on the Sound Traveller team. The team must choose a data-tracking approach, then build a customer-facing redirect button under a launch deadline. ### Part 2.1 — Ada compares data-tracking options Ada is comparing two tracking options: a third-party vendor called **Number-House** or building an **internal** data-tracking platform. Number-House is faster to launch; an internal build has long-term cost and control benefits. Rate the **value of each benefit** for helping Ada make a recommendation: - **A.** Number-House supports an on-time launch. - **B.** Number-House eliminates the need to build a customized solution. - **C.** An internal platform is more cost-effective in the long term. - **D.** An internal platform can be customized for Sound Traveller's future feature needs. ```hint Here you're rating how *decision-relevant* each stated benefit is, not which vendor to pick. Ask of each one: is this a concrete, durable factor a recommendation can actually rest on (launch timing, long-term cost, future control), or is it a softer convenience framed as a benefit? ``` #### What This Part Should Cover - **Decision-relevance of each benefit** — does it bear directly on a recommendation (launch timing, long-term cost, future control) or is it soft? - **Distinguishing a concrete, durable factor from a restated convenience** — is the benefit a standalone strategic reason to choose a vendor, or is it a secondary implication of another benefit? - **Balanced weighing of short-term (launch) vs. long-term (cost, customization) value** rather than favoring one axis reflexively. ### Part 2.2 — Mai asks for a redirect-button proposal Leadership chooses Number-House to ensure an on-time launch. Mai asks you to start the redirect button and send a brief proposal for how you plan to build it. Rate these **questions to ask Mai before writing the proposal**: - **A.** Is there any flexibility in the timeline? - **B.** Are there examples of similar features that can be referenced? - **C.** Which existing systems must the button integrate with? - **D.** Which API must the button call? - **E.** Should customers still be redirected if the tracking API fails? ```hint The decision has already been made for speed, so consider whether a timeline-flexibility question still materially changes the proposal. Weigh each question by how directly its answer constrains a correct, customer-safe design — questions that pin down the technical contract versus ones that are nice-to-have context. ``` #### What This Part Should Cover - **Pinning down the technical contract** — understanding what existing systems, APIs, and failure behaviors are involved before writing a proposal. - **Customer-safety questions** — what happens to the customer experience when a dependency fails is a high-value design question. - **Recognizing the current decision context** — how much new information a question actually adds depends on what leadership has already resolved. ### Part 2.3 — Kyle says he is on track, but you believe he is not Kyle says he told Mai he is on track, but after reviewing his code you believe he is unlikely to finish on time. Rate these actions: - **A.** Email the Sound Traveller team and say you have concerns with Kyle's code and timeline. - **B.** Tell Mai that you reviewed Kyle's code and are concerned because of the amount of change still needed. - **C.** Raise your concerns about Kyle's code during the team meeting later that day. - **D.** Tell Kyle that because he is unlikely to meet his deadline, he should inform Mai so the lead can provide support and guidance. - **E.** Hold off on sharing concerns because Kyle is responsible for updating the status of his own code. ```hint There's a real, evidence-backed schedule risk, so weigh each action on two dimensions: the *audience* it reaches (the whole team, the lead, just Kyle, or no one) and the *timing* (now vs. later, vs. staying silent). Consider how each combination affects both the schedule risk and the person whose work is in question. ``` #### What This Part Should Cover - **Audience appropriateness** — a private, evidence-based heads-up to the responsible lead vs. a team-wide broadcast that embarrasses the peer, vs. silence. - **Timeliness of the escalation** — acting now to give the lead lead-time vs. waiting for a later meeting. - **Acting on evidence, not deferring** — a reviewed-code concern is a real risk that shouldn't be left to Kyle's self-reporting alone. ### Part 2.4 — Kyle asks for final code approval Kyle updates his code and gets Ada's approval. Before **final** approval, you notice his approach could cause errors for a **small subset of customers**. Rate these actions: - **A.** Ignore the potential issue because Ada already approved the code. - **B.** Approve the code to launch on time, but ask Kyle to build a patch after launch. - **C.** Tell Ada what you found and ask whether Kyle's code should be revised before deployment. - **D.** Leave a code-review comment documenting the issue and withhold approval until it is addressed. - **E.** Add a code comment documenting the issue so it can be fixed shortly after launch. ```hint You are at the approval gate and you know about a defect that would reach real customers. Weigh whether a known customer-impacting issue should be allowed through the gate at all, and how the actions differ in what they actually do to the launch — withholding approval, routing the decision to a stakeholder, or merely recording the issue while the code still ships. ``` #### What This Part Should Cover - **Using the approval gate as a quality control point** — what an approver's authority actually means when a known defect is present. - **The gap between documenting an issue and preventing it** — passive record-keeping vs. active blocking differ in customer outcome. - **When to escalate to a stakeholder vs. act within your own authority** — understand what each action actually does to the launch path. --- ## Module 3 — Games team: testing and launch pressure You are on the Amazon Games team. Product (Monique) pushes for speed; testing, code review, and customer-impacting quality are repeatedly at risk. Amber owns testing/quality standards. ### Part 3.1 — Official-site button bug The "Visit the Official Site" buttons are broken — customers stay on the games page instead of being redirected. Amber believes the fix will take **four days** and requires new unit tests, but Monique asks for a fix by **end of day**. Rate these testing strategies: - **A.** Write the code and ask the team to review it **before** running tests so you can get immediate feedback and make edits. - **B.** Write new unit tests that specifically validate the fix. - **C.** Conduct manual testing first, then create automated tests immediately afterward. - **D.** Run only a subset of tests to spot-check the changes and publish if the spot-check passes. - **E.** Roll back to a previous version as a quick fix, then work on fully tested new code. ```hint This is a live customer-facing bug under deadline pressure. Evaluate each strategy on two things: how well it actually *validates* the fix, and how it *manages customer risk right now*. Some strategies substitute review for testing, some trade coverage for speed, and some restore service first and test after — each makes a different bet. ``` #### What This Part Should Cover - **How well the strategy validates the fix** — purpose-built tests vs. a partial spot-check vs. review standing in for testing. - **Immediate customer-risk management** — rollback as a legitimate mitigation that restores service while the proper fix is built and tested. - **Coverage vs. speed tradeoff** — recognizing that skipping or thinning tests on a customer-facing bug is a weak bet. ### Part 3.2 — Ajay wants limited testing Ajay is updating a **purchase** feature. Monique wants speed. Ajay plans to do manual pre-production testing and **skip** new integration testing. Rate these actions: - **A.** Remind Ajay that automated testing is more likely to catch errors than manual testing. - **B.** Inform Amber so she knows about Monique's request and Ajay's limited-testing plan. - **C.** Tell Ajay that testing should not be skipped and offer to help with new integration testing. - **D.** Encourage Ajay to work with Amber and Monique to find a compromise between testing timelines and product updates. - **E.** Tell Ajay his decision makes sense because meeting the deadline is most important. ```hint This is a purchase flow, so weigh how each action treats the testing standard under deadline pressure — whether it upholds it, gives the quality owner visibility, merely states a fact, or endorses skipping. Also notice which actions actually *do something about the bottleneck* versus which only comment on it. ``` #### What This Part Should Cover - **Upholding the testing standard on a purchase (customer-money) path** rather than endorsing skipped integration tests. - **Giving the quality owner (Amber) visibility** when launch pressure collides with the testing standard. - **Acting on the bottleneck vs. only commenting** — distinguish responses that change the situation from responses that only observe or advise on it. ### Part 3.3 — Jonas asks for quick approval Jonas is updating an in-game **purchase** feature. He planned two days for testing but skipped tests he thinks are unnecessary so the update can launch sooner. He asks you to quickly review and approve. Rate these actions: - **A.** Tell Jonas to contact Amber to make sure he considered all necessary edge cases. - **B.** Send Jonas error reports from previous projects where code was published without complete testing. - **C.** Set aside your work and help Jonas run a complete set of tests on his code. - **D.** Wait for Ajay to give feedback and approval before providing your own feedback and approval decision. - **E.** Approve Jonas's code because Monique is right that the deadline matters. ```hint You are the approving reviewer here, on a purchase feature with skipped tests. Weigh each action by how directly it moves toward the *correct* outcome — actually getting the necessary tests run before approval — versus actions that nudge from a distance, defer the decision to someone else, or approve as-is. ``` #### What This Part Should Cover - **Directly driving the correct outcome** — getting the necessary tests run before approval, not approving under-tested purchase code. - **Owning the approval decision** rather than deferring it to another reviewer. - **Distinguishing direct action from distant nudges** — hands-on help beats pointing him at the quality owner or past error reports. ### Part 3.4 — Amber asks for testing guardrails Amber says there have been several recent cases where code was published **without proper testing**. She asks for ideas to prevent this from recurring. Rate these recommendations: - **A.** Set up automations that **prevent** deployments without required testing. - **B.** Create standard operating procedures that define testing requirements. - **C.** Research the root cause of the incidents and share findings with the team. - **D.** Set up guidelines for **troubleshooting** code after it is deployed without proper testing. ```hint Amber's goal is to stop the problem from *recurring*. Sort these by where in the timeline each one acts: does it mechanically prevent the bad release, define expectations that rely on people following them, investigate causes, or deal with the aftermath once an untested deploy has already happened? ``` #### What This Part Should Cover - **Where in the timeline each idea acts** — before, during, or after an untested deploy can reach production. - **Enforcement vs. reliance on discipline** — some solutions make the bad outcome structurally impossible; others depend on people choosing to follow them. - **Prevention vs. cleanup** — distinguish ideas that stop the problem from recurring vs. ideas that manage consequences after it happens. --- ### What a Strong Answer Covers These dimensions span all parts — they are the cross-cutting pattern the assessment measures (this checklist is *what is measured*, not the ratings themselves): - **Ownership** — keeps the next concrete step with you; doesn't hand off the problem, the decision, or the code. - **Earn Trust / communication** — transparent, specific, timely status; takes feedback (especially senior feedback) seriously without rubber-stamping it. - **Customer obsession & highest standards** — refuses to ship known customer-impacting defects or to skip necessary testing on customer-critical paths (purchases, redirects). - **Bias for action & appropriate escalation** — acts now, escalates early to the *right* person privately, and avoids both silence and premature broadcasting. - **Collaboration vs. abdication** — distinguishes genuinely engaging others from offloading responsibility onto them. - **Dive deep on tradeoffs** — understands the technical/decision tradeoff personally rather than deferring to whoever spoke last. - **Internal consistency** — the relative scores within a scenario reflect a coherent value ordering (e.g., prevent > escalate > document-for-later > ignore). ### Follow-up Questions 1. Pick one scenario and justify *why* your top-rated and bottom-rated responses differ — which specific Leadership Principles separate them? 2. In Part 2.4 (and 3.3), you found a known issue at the approval gate. Walk through how you would block the launch while *still* respecting the deadline pressure — what do you say to Monique/Ada and in what order? 3. Several scenarios pit "speed" against "quality/testing." Describe a concrete mechanism (process or tooling) that would let the team move fast *without* repeatedly relitigating whether to skip tests. 4. When is escalating to a lead the right move versus coaching a peer to self-report? Give the signals you'd use to decide.