Amazon & AWS Behavioral & Leadership interview questions

An incident answer needs your actual decisions, the evidence behind them and the effect on users. A wrong turn belongs in the story only if it happened.

Explain a technical disagreement you lost, how you supported the chosen implementation and which evidence would justify reopening the decision.

Prepare an accountable account of a technical mistake: disclosure, recovery decisions, a tested prevention measure and the residual risk.

Explain mentoring through an observed blocker, a bounded owned task, useful feedback and evidence that the engineer can apply the learning independently.

Explain a reliability objection through the failing mechanism, a feasible alternative and an explicit decision about the remaining service risk.

Coordinate a major incident through explicit roles, bounded investigations, safe recovery decisions and a handoff that preserves current state.

Defend a change with irreversible effects by separating code rollback, data recovery and external correction, with explicit recovery objectives and tested limits.

Decide whether to continue a migration using remaining costs and current benefits, then deliberately operate or unwind the partial state.

Transfer incident responsibility with current impact, evidence-qualified hypotheses, active changes and the next authorized decision, followed by explicit acceptance.

A screening question that filters out people who have read about the field rather than looked at it. The answer that fails is a list of tools; the one that works describes who you serve and what you are on the hook for.

Turn difficult feedback into a testable improvement, while checking its factual basis and keeping unfair or inappropriate treatment separate.

The first question, the one people prepare least, and the only one where you choose what the rest of the interview is about. Two minutes, ending on something you want to be asked about.

The question is really whether you learn deliberately or absorb whatever passes by. One specific thing learned recently, with why you picked it and what you did with it, beats any list of newsletters.

Turn a deadline dispute into a reviewable plan with capacity arithmetic, dependencies, scope choices and a clear acceptance boundary.

Assess a late deployment through change scope, recovery evidence and support coverage, then make a concrete release or deferral recommendation.

Facilitate a disputed design by stopping personal attacks, separating testable assumptions from priorities and assigning a decision owner.

Investigate on-call workload with responder feedback and paging evidence, then verify that relief and alert changes preserve service coverage.

Use shared evidence and an agreed experiment to resolve a cross-team production problem, while containing impact and escalating time-sensitive risk.

Correct mistaken incident attribution with evidence, protect the response from a false diagnosis and follow through on the shared record.

Communicate a threatened delivery or recovery commitment with known facts, uncertainty, a recommendation and the decision needed before options expire.

Delegate a technical outcome with authority, capacity and acceptance criteria, while preserving the decisions and commitments assigned to the lead.

Resolve competing urgent requests using consequences, deadlines, uncertainty and real capacity, with explicit decisions about deferred work.

Address repeated test and review bypasses through verified evidence, immediate risk containment and a repair that preserves the required coverage.

Make early incident reporting practical through a usable escalation path, constructive response and visible corrective work, without turning reports into a performance quota.