Amazon Game Developer (Mid-Level) Interview Preparation Guide

Direct answer. Start with compiler warnings (-Wall -Wextra), then build the tests and a fuzzing harness (a fuzzer feeds a program huge numbers of automatically generated or mutated inputs, and the harness is the small entry point that hands each input to the code under test) with AddressSanitizer plus UndefinedBehaviorSanitizer (-fsanitize=address,undefined -g -fno-omit-frame-pointer); AddressSanitizer includes LeakSanitizer on Linux. For binaries you cannot rebuild, or to see uninitialized reads, run under Valgrind's Memcheck (a tool that runs your unmodified program under its own checker, watching every memory access). Read each report in the same order: error type, the access (read or write, size), the faulting stack with file and line, then the allocation and free stacks, and only then decide the fix.

What each tool is for

Start with AddressSanitizer plus UndefinedBehaviorSanitizer in one build; the other rows cover what they do not.

One program, four bugs

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
int main(int argc, char **argv) {
    int which = argc > 1 ? atoi(argv[1]) : 0;
    int *a = malloc(4 * sizeof *a);
    if (which == 1) a[4] = 1;                 /* heap overflow by one element */
    else if (which == 2) { int big = INT_MAX; big += argc; printf("%d\n", big); } /* signed overflow */
    else if (which == 3) { free(a); a[0] = 1; a = NULL; } /* use after free */
    else if (which == 4) { a = NULL; }        /* leak */
    if (which != 3 && which != 4) free(a);
    return 0;
}

Built with gcc -g -O1 -Wall -Wextra -fsanitize=address,undefined -fno-omit-frame-pointer s8.c -o s8, run as ./s8 N: (the reports below are trimmed: libc and runtime-library frames, the pointer points here hex dump and the shadow-byte map are left out, and ... marks other elisions. The compiler also prints a -Wuse-after-free warning for the which == 3 line, which is the first hint of that bug.)

./s8 1 (heap overflow, one int past a 4-element array):

s8.c:7:26: runtime error: store to address 0x502000000020 with insufficient space for an object of type 'int'
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000000020 ...
WRITE of size 4 at 0x502000000020 thread T0
    #0 ... in main /w/s8.c:7
0x502000000020 is located 0 bytes after 16-byte region [0x502000000010,0x502000000020)
allocated by thread T0 here:
    #1 ... in main /w/s8.c:6

./s8 2 (UBSan; note the program keeps running and prints the wrapped value):

s8.c:8:51: runtime error: signed integer overflow: 2 + 2147483647 cannot be represented in type 'int'
-2147483647

./s8 3 (use after free): ERROR: AddressSanitizer: heap-use-after-free ... WRITE of size 4, then freed by thread T0 here at line 9 and previously allocated by thread T0 here at line 6.

./s8 4 (leak): ERROR: LeakSanitizer: detected memory leaks and Direct leak of 16 byte(s) in 1 object(s) allocated from: ... main /w/s8.c:6, with SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).

Valgrind Memcheck on the same kind of bugs

Valgrind needs no rebuild, but its manual asks for -g so messages carry line numbers, and it warns the program runs much slower (20 to 30 times) and that Memcheck cannot detect out-of-range accesses to static or stack arrays. A small program (saved as vg.c, so the line numbers below count the two #include lines), built with gcc -g -O0 vg.c -o vg and run as valgrind --leak-check=full ./vg N (arm64 Linux):

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
    int which = argc > 1 ? atoi(argv[1]) : 0;
    int *a = malloc(4 * sizeof *a);
    if (which == 1) a[4] = 1;                 /* heap overflow by one element */
    else if (which == 2) { int u; if (u > argc) puts("big"); } /* uninitialized read */
    free(a);
    return 0;
}

$ valgrind --leak-check=full ./vg 1
==197== Invalid write of size 4
==197==    at 0x400760: main (vg.c:6)
==197==  Address 0x4a7f050 is 0 bytes after a block of size 16 alloc'd
==197==    at 0x488545C: malloc (vg_replace_malloc.c:446)
==197==    by 0x400743: main (vg.c:5)
$ valgrind --leak-check=full ./vg 2
==201== Conditional jump or move depends on uninitialised value(s)
==201==    at 0x400780: main (vg.c:7)

The first report reads like ASan's: an invalid write of 4 bytes, directly after a 16-byte block allocated at line 5. The second is the kind of bug ASan's documented list does not cover: a branch decided by a variable that was never set. (Both Memcheck reports are trimmed to their error blocks: the startup banner, HEAP SUMMARY and ERROR SUMMARY lines are left out. ==197== is the process id; the addresses are illustrative.)

How to read a report

1. Headline: heap-buffer-overflow, heap-use-after-free, stack-buffer-overflow, attempting double-free, SEGV on unknown address. This names the class.
2. Access line: WRITE of size 4. A write is more dangerous than a read (corruption, possibly exploitable).
3. First stack: the first frame in your code is where the bad access happened. Frames inside the runtime library are noise.
4. Region line: located 0 bytes after 16-byte region means a one-past-the-end overflow (off-by-one loop or <=). A large offset means a wild index or a wrong length. 0 bytes inside plus a "freed by" stack means use after free.
5. Second and third stacks: who freed it and who allocated it. For use-after-free the question is why a pointer outlived the free: it is almost always a second owner.
6. Leaks: Direct leak is a block no pointer reaches, with the allocation stack and size. Leaks are reported at exit, so exit the program cleanly in tests.

Triage order for a suspected bug

1. Reproduce with a sanitizer build and the failing input. If it fails only without the sanitizer, suspect an uninitialised read: Memcheck reports those, and ASan's documented list does not include them.
2. Read the report in the order given in the previous section and fix the first reported error; later ones are often consequences.
3. Add the failing input as a regression test and keep the sanitizer build in CI.
4. Check for a false positive only after the report's allocation and free stacks fail to make sense; remember ASan's own HINT line: it may be a false positive if the program uses a custom stack unwind mechanism (code that jumps around the stack on its own), swapcontext (saves the current execution context and switches to another, which gives it its own stack) or vfork (creates a child process that shares the parent's memory, stack included, until it execs or exits).

Pitfalls

• No -g or an optimized-away frame pointer (the register compilers keep pointing at the current call's frame, which tools follow to list the callers; -fno-omit-frame-pointer keeps it) gives hex offsets with no line numbers.
• A clean sanitizer run proves nothing about inputs the tests never reached; pair sanitizers with a fuzzer or realistic corpora.
• Sanitizers change memory layout and timing; a bug that only shows without them still needs a debugger and a core dump (the file the operating system writes when a process crashes, holding an image of its memory at that moment, which a debugger such as gdb can open).

Design: Use a federated learning hybrid with secure aggregation and differential privacy. Data flow: On-device training generates model updates (gradients) privately; local pre-processing and quantization reduce footprint. Devices send encrypted, clipped updates to an aggregator; the aggregator performs secure aggregation to compute an averaged global update without seeing individual updates. Apply central model improvement steps (server-side validation, learning-rate tuning), then inject differentially-private noise to the aggregated update before applying to global model. Model update cadence: frequent on-device rounds (daily for personalization), centralized aggregation weekly or biweekly depending on stability and bandwidth. Privacy mechanisms: per-device clipping, secure aggregation (cryptographic protocols), and add calibrated DP noise (epsilon tuned per rollout). Also maintain on-device personalization layers (small heads) that never leave device. Validation: server-side holdout evaluation, shadow models, and on-device A/B canaries to ensure no regressions. Governance: track cumulative privacy budget, require privacy review for any change to aggregation or noise parameters, and maintain explainability logs. Trade-offs: balance between personalization speed and privacy budget; choose hyperparameters to fit expected device participation and network constraints.

Requirements & constraints

• Multiple stacked screens (MainMenu, Settings, CharacterSelect, InGameHUD), modal dialogs (confirm, store), smooth transitions, async asset load/unload, input focus, deep links (e.g., game://character/123), mobile/PC/console input.

High-level design

• Single NavigationManager owning a ScreenStack + ModalLayer + ResourceLoader + TransitionController. Screens are lightweight controllers that request assets then become active.

Public API (example)

interface INavigationManager {
  Task PushScreen(ScreenDescriptor desc, TransitionSpec t = null); // async: loads assets, runs enter transition
  Task PopScreen(TransitionSpec t = null); // async: exit transition, then unload if not cached
  Task ShowModal(ModalDescriptor desc); // modal semantics: blocks background input but not rendering
  Task DismissModal(string modalId);
  void HandleInput(InputEvent e); // routes to focused element
  Task HandleDeepLink(Uri link); // resolves to navigation actions
  void Preload(ScreenDescriptor desc); // start loading without activating
}

Modal semantics & focus

• ModalLayer is separate stack; modals capture input focus exclusively; background screens remain rendered but input-disabled unless modal is non-blocking (toast).
• Focus model: focusedScreen = top modal if exists else top of ScreenStack. UI elements register focusable IDs; NavigationManager routes input to focusedScreen.

Async loading/unloading

• ResourceLoader returns Task<AssetBundle>. PushScreen awaits ResourceLoader.Load(desc.assets) with cancellation token. Show a low-cost placeholder or loading HUD. Unload when screen popped and refcount=0; support caching policies per descriptor (KeepAlive, MemorySensitive).

Transitions & interruption

• TransitionSpec declares animation, duration, easing. Push/Pop run transitions atomically; allow interrupt by queuing new navigation — current transition canceled gracefully (reverse animation) or completed fast-forward.

Deep links

• DeepLinkResolver parses URI -> sequence of PushScreen/ShowModal/SetState. Example: game://character/123 -> PushScreen(MainMenu) if not present, Push Screen(CharacterSelect, initialId=123), open CharacterDetail.

Example scenario

• Deep link to character: NavigationManager.HandleDeepLink parses, Preload CharacterSelect assets, PushScreen(CharacterSelect) with enter transition, pass characterId, focus set to character tile, open modal for purchase if needed.

Trade-offs

• Single manager simplifies orchestration but centralizes logic; consider splitting TransitionController for complex animation graphs. Caching reduces load stall but increases memory.

This design provides clear async semantics, deterministic input focus, modal isolation, and an extensible API suitable for Unity/C# or C++ engines.

Overview of common formats

• BC1–BC7 (DXT family): Block-compressed 4x4 texels. BC1 = RGB (1-bit alpha), BC3 = interpolated alpha, BC4/5 single/dual-channel, BC7 = high-quality RGB/RGBA. Widely supported on PC/console GPUs (DX/OpenGL/Vulkan).
• ETC1/ETC2: 4x4 blocks used on mobile. ETC1 = RGB (no alpha); ETC2 adds full alpha support and higher quality—mandatory for OpenGL ES 3.0.
• ASTC: Flexible block sizes (from 4x4 up to 12x12), supports HDR/alpha, excellent quality-per-bit. Supported on modern mobile GPUs and desktop GPUs with drivers.

Trade-offs

• Quality vs bitrate: Smaller blocks (4x4) = better quality, higher bitrate. Larger blocks = lower bitrate, lower quality.
• Alpha: BC1/ETC1 lack proper alpha; BC3/BC7/ETC2/ASTC handle alpha with varying quality/cost.
• Block size/bitrate: BC family fixed 4x4 (typically 4–16 bpp variants); ETC ~4 bpp; ASTC selectable (0.89–8 bpp effective).
• Platform availability: BC family ubiquitous on consoles/PC; ETC common on older Android; ASTC increasingly common on modern mobile (preferred on iOS/M1+).
• GPU decode cost: All are hardware-decoded and cheap relative to runtime sampling; ASTC slightly higher decode complexity but negligible on supported hardware.

Format selection strategy

• Mobile builds: Prefer ASTC where supported (best quality/bitrate flexibility). Fall back to ETC2 for broad Android support; include ETC1 with separate alpha atlas only for very old devices. Target per-asset block sizes (e.g., 6x6/8x8 for UI, 4x4 for character textures) to balance memory.
• PC/console builds: Use BC7 for high-quality RGBA assets, BC1/BC3 for legacy or low-bandwidth cases, BC5 for normal maps. Keep one high-quality format (BC7) and one cheaper format for low-end targets.

Rationale: choose formats that maximize visual fidelity per memory budget while matching hardware support to avoid costly software decoding or large fallback textures.

Clarify scope & constraints
We’re migrating saved game state (player inventory, world objects, positions) while live players and long-lived saves exist. Key goals: preserve player progress, avoid downtime, and enable rollback.

Eager migration (during update)

• Approach: Run a server-side migration job that upgrades all save blobs to vN before players reconnect; block old clients or accept reads only.
• Operational risk: Medium–high (large batch jobs can strain DB, long lock windows, rollback harder).
• User impact: Low after release (players see new model immediately) but may face downtime or slower logins during migration.
• Complexity: Medium — write deterministic migration scripts, batch/stream processing, transactional safety, throttling.

Lazy migration (on load)

• Approach: Keep versioned saves; transform each save when a player loads it for first time.
• Operational risk: Low — avoids mass operations, progressive rollout.
• User impact: Medium — first load may have latency or slight gameplay differences; possible partial failures need recovery.
• Complexity: Low–medium — need per-save migration code, migration safety checks, and idempotency.

On-the-fly adapters

• Approach: Implement runtime adapters that read old schema and map to new model without mutating storage; optionally write back asynchronously.
• Operational risk: Low — minimal DB operations; risk is increased runtime complexity.
• User impact: Minimal immediate impact; consistent behavior if adapter correct.
• Complexity: High — must support multiple versions concurrently, add testing matrix, and may complicate game logic/performance (especially on constrained clients).

Recommendation
For game releases: prefer lazy migration for safety and fast rollout; pair with telemetry and a short-lived adapter to handle edge cases. Reserve eager migration for small, well-tested changes or when adapter/perf cost is unacceptable. Ensure: versioned schema, idempotent migration code, feature flags, backups, and automated tests (unit + integration using representative save data).

Direct answer

A go or hold call under last-minute risk is not a coin flip between shipping and not shipping. It is a structured judgment: gather just enough information fast to size the real risk rather than the scariest-sounding version of it, pull in the specific people who know something you do not, weigh severity and reversibility against the actual cost of delay, and if you ship, ship in a way that limits the blast radius and gives you an early warning if you were wrong.

Structured elaboration

Gather information quickly. Get the specific facts, not the summary: what exactly is affected, how often does it reproduce, what does the actual worst case look like rather than the feared one, and how confident is anyone in that assessment. Timebox this to something like an hour rather than a full day, because an open-ended investigation under real time pressure is itself a decision to slip the launch.

Decide who weighs in. Whoever built or owns the thing now in question, since they know the real mechanism. Whoever owns the user or business impact if it goes wrong, since they know what "bad" actually costs. And anyone with the authority to accept that cost on the organization's behalf if it is significant, not because every call needs permission but because some costs are not yours alone to accept.

Weigh the trade-offs. On one axis, how bad and how likely is the downside. On the other, what does delay actually cost, a fixed external commitment, competitive timing, or just discomfort. A rare, low-severity issue against a large delay cost usually ships. A rare but severe and hard-to-reverse issue usually does not, regardless of the delay cost.

If shipping anyway. Define mitigations that specifically reduce the exact risk identified, not generic ones. Have a rollback plan you could execute quickly if the worst case starts to materialize. Prefer a phased, monitored rollout, a small percentage of traffic or users first, over an all-at-once launch, with a specific signal you are actively watching to catch the problem early if it happens.

Worked example

The day before a planned release, testing finds that a specific action sequence causes intermittent save-file corruption in roughly one out of every few hundred attempts, and the root cause is not yet fully understood.

In the first hour, the team confirmed it only reproduces under that specific sequence, confirmed it is a real data-corruption risk rather than a cosmetic glitch, and confirmed they could reliably trigger it without yet fully explaining why. The engineer most familiar with the save system weighed in on the mechanism, the producer who owned the cost of slipping the date (a marketing push already scheduled) weighed in on the delay side, and the studio lead weighed in because losing a player's save data is a severe, hard-to-reverse harm to trust. Severity was high, a corrupted save has no clean undo for the affected player, and reversibility was poor, while the cost of a short delay was real but recoverable, a marketing push could shift by a few days. Given a severe, poorly reversible risk against a recoverable delay cost, the call was to hold the original date.

What shipped instead a few days later was a scoped mitigation, a patch disabling the specific action sequence that triggered the bug, released through a phased rollout: 5% of players first, with save-corruption reports monitored hourly for the first two days, before expanding to everyone once that window passed clean.

Trade-offs and pitfalls

The most common failure is treating this as a single binary decision made once, rather than a call that gets revisited as new information arrives during the timeboxed investigation. A second is skipping the person who owns the cost of being wrong, whether that is a support team who will field complaints or a user who is genuinely harmed, because it feels uncomfortable to loop them in this late. A third is deciding to ship anyway with mitigations that sound reassuring but do not specifically address the actual failure identified. A general promise to monitor closely is not a mitigation for a known, specific failure mode.

Overview (why it matters for game dev)
Engines are usually native C++ for performance; scripting languages let designers iterate gameplay quickly. Integration pattern choice affects performance, tooling, and debugging.

Binding approaches

• Embedding interpreter: Link Lua/Python runtime into the engine, execute scripts, call into C++ via a C API. Lightweight and fast for Lua; good for modding.
• C API / manual bindings: Use the language's C API (Lua C API, Python C-API) to push/pop values and register functions. Fine-grained control, minimal overhead, but boilerplate-heavy.
• Generated bindings: Use tools (SWIG, pybind11, C#-mono embedding or C++/CLI, or automated bindings for C# via Il2Cpp/mono) to auto-generate glue. Fast to develop and maintain; can incur abstraction overhead.

Common interop pitfalls

• Garbage-collection stalls: Scripts triggered on the main thread can cause GC pauses. Mitigate by explicit incremental GC, spreading allocations, or running script VMs on worker threads for non-UI tasks.
• Expensive marshaling: Converting complex structs, strings, or arrays each frame is costly. Use shared memory buffers, binary blobs, or pass handles/IDs instead of copying objects frequently.
• Reverse calls (script -> engine callbacks): Frequent callbacks across the boundary are costly and can create unpredictable timing. Batch calls, use event queues, or cache function references.
• Thread-safety: Most runtimes (Lua, CPython, Mono) are not fully thread-safe by default. Use per-thread VM instances, mutexes, or message passing. For C#, beware of the managed thread-affinity (Unity main-thread requirements) and synchronizing with the engine.

Practical tips

• Profile boundary crossings and GC.
• Keep hot loops purely native or use lightweight JIT-friendly patterns.
• Expose minimal, high-performance APIs (IDs, DTOs) rather than marshalling big graphs.
• Provide tooling: script debugging, stack traces, and safe sandboxing for modders.

Direct answer
A strong answer to "tell me about a time you failed" or "a time you fell short of one of our values" does three things: it names the failure honestly without over-apologizing or explaining it away, it ties the failure to a specific principle or value rather than a vague "I learned to work harder," and it spends more time on the concrete change made afterward than on the failure itself.

Structured elaboration

• Situation and task: set up briefly; this should not be the bulk of the answer.
• The failure itself: describe plainly what happened, and own your specific part in it ("I failed to X," not "the team failed").
• The principle reflection: name which principle or value, in hindsight, you underweighted in the moment. For example, you may have optimized for looking on-track when the situation called for earlier transparency, or vice versa.
• Result and change: the concrete thing you actually changed (a process, a habit, a communication pattern), and how you know it held up, ideally with a later situation where the new behavior was tested.

Worked example
A candidate had committed to a two-week delivery timeline for a partner team without validating a key dependency first. The dependency slipped, and the candidate didn't flag the risk until the deadline itself, leaving the partner team no time to re-plan. In hindsight, they had underweighted early, uncertain communication in favor of appearing on-track. Afterward, they changed their habit: the moment any dependency looks uncertain, they send a short "this is at risk" note rather than waiting for certainty. Two commitments since then have both surfaced early warnings, giving the receiving team time to adjust rather than being surprised at the deadline.

Trade-offs and pitfalls
A common miss is choosing a "failure" that is actually a humble-brag, a failure that reads as impressive; interviewers notice this quickly, and it undermines the self-awareness the question is testing. Spending most of the answer narrating the failure and only a sentence on the change inverts what the question actually tests; the change and the evidence it worked should take up the majority of the answer. A lesson stated too generically ("I learned to communicate more") is weaker than naming the specific behavioral change that resulted.

Direct answer. Add a thin safety net first (characterization tests around the highest-risk paths), then make the smallest behavior-preserving changes that let you keep shipping features on top of a codebase that's incrementally getting safer -- never stop feature delivery to do a big-bang rewrite.

A pragmatic, incremental plan

1. Triage by risk, not by ugliness: use bug/incident history and traffic volume to find which parts of the codebase actually cause production pain, rather than starting with whatever looks messiest to the eye. That's where safety-net investment pays off fastest.
2. Characterization tests around the riskiest, most-touched code first: pin current behavior before changing anything there, so the very next change (a bug fix someone was going to make anyway) has a safety net.
3. Introduce seams for testability opportunistically: when you're already touching a function for a bug fix or small feature, take the extra step to extract its logic behind a seam (dependency injection, a wrapper around a hard-to-test dependency) rather than scheduling a separate 'add tests' project that competes with feature work indefinitely.
4. Establish a ratchet, not a rewrite: a simple rule like 'code you touch must leave with equal or better test coverage than it had' compounds over months without ever requiring a stop-the-world effort.
5. Fix bugs as they're found, but track root causes: if the same TYPE of bug (e.g., null handling) recurs, that's a signal for a small, targeted structural fix (a value type, a validation layer) rather than continuing to patch individual symptoms.
6. Communicate progress in business terms: incident rate trending down, cycle time on bug fixes shrinking -- so the ongoing investment stays visible and defensible against pressure to 'just ship features.'

Why NOT a big rewrite

A rewrite requires understanding the FULL current behavior (including undocumented edge cases relied on by real users) well enough to reproduce it exactly, which is precisely the thing 'frequent production bugs and no tests' tells you the team does NOT currently have -- the rewrite would be built on the same uncertain understanding that caused the bugs in the first place, at much higher risk and with a long period of zero feature delivery.

Trade-offs and pitfalls

• This plan trades a fast dramatic fix for a slower, compounding one; if leadership expects a visible turnaround in weeks rather than months, be explicit up front about that mismatch rather than overpromising a timeline the approach can't deliver.
• The 'ratchet' rule needs actual enforcement (a CI coverage-delta check, or review discipline) or it silently stops being followed the first time a deadline gets tight -- decide in advance whether it's a hard gate or a norm, and be honest that a norm alone often erodes under pressure.

Direct answer

Here is the shape of a good answer, which you fill with your own real story if you have one. I found something that was good for customers but cost near-term revenue, sized the real cost (usually smaller than the headline), identified what we would watch to learn the long-term effect, and got agreement for a time-boxed test with a stop condition. I commit to the customer-good option when the loss is bounded and measurable, and the harm to customers is clear.

Weighing it

1. Size the true short-term cost, net of refunds, chargebacks (a customer disputes the charge with their bank, which costs the business the money plus a fee) and support cost, not the gross headline (the top-line revenue figure before refunds and other costs).
2. Name the customer harm: who pays or suffers today, and how.
3. Choose leading indicators (early measurements that move before the long-term result does) for the long-term benefit (not just "trust will improve"): refund rate, support contacts, repeat purchase at 90 days.
4. Propose a bounded test with finance agreeing the cost ceiling (the most revenue the team accepts losing during the test) beforehand.
5. Decide the stop rule and what would flip your call.

Worked example (illustrative numbers)

A checkout shows a pre-checked $5 add-on. Assume 10,000 orders a month. With the box pre-checked, 600 orders keep the add-on: gross add-on revenue is 600 times $5 = $3,000 a month. 150 of those 600 later request a refund, so 450 orders at $5 = $2,250 a month is kept. If the box becomes opt-in, assume 200 orders choose it with almost no refunds: 200 at $5 = $1,000 a month.

Headline loss quoted by the revenue team: $3,000 minus $1,000 = $2,000 a month. Net loss after refunds: $2,250 minus $1,000 = $1,250 a month, or $15,000 a year (12 times $1,250). The $15,000 is a real cost; it is also smaller than the headline, and it is bounded. Support cost shrinks it further. At an illustrative $4 of agent time per refund request, 150 requests cost $600 a month, so the net loss is $2,250 minus $600 minus $1,000 = $650 a month, about $7,800 a year (12 times $650). I would present the refund-only $15,000 as the conservative ceiling and the support-adjusted figure as the likely cost.

The case for it is not "customers will love us": 150 refund requests a month is a measurable harm, each one a customer who felt tricked. The proposal: A/B test (two versions shown to different random groups) opt-in for one month, with the cost ceiling agreed with finance, tracking refund rate, support contacts and 90-day repeat purchase. The stop rule: if repeat purchase does not improve or support contacts do not fall, revisit.

Convincing others

Present the net cost, not the gross; let finance own the ceiling; show the customer complaints in their own words; offer a smaller first step.

Pitfalls

• Claiming long-term benefit with no mechanism to check it. "Trust" is not a number.
• Hiding the cost. State the net cost first, as a ceiling.
• Moralising. Frame as risk and customer evidence, not as ethics against colleagues.