What do interviewers evaluate in Earn Trust questions?

Interviewers listen for signals like: Are you vocally self-critical - do you name your own mistakes plainly, or shade them into 'lessons learned' that blame circumstances? Do you deliver bad news early and directly, or sit on risks hoping they resolve themselves? Can you take direct feedback without defensiveness and act on it visibly?

gitGood.dev

Amazon LPFoundational Premium

Earn Trust (Amazon Leadership Principle)

Amazon's bar for how leaders build credibility: listen, speak candidly, treat others respectfully, and be vocally self-critical even when it is awkward.

About this theme

Earn Trust is the principle that leaders listen attentively, speak candidly, and treat others respectfully, are vocally self-critical even when doing so is awkward or embarrassing, and do not believe their or their team's body odor smells of perfume. They benchmark themselves and their teams against the best. For an engineer it shows up as admitting your own mistakes plainly, giving and receiving direct feedback without defensiveness, being transparent about risks and bad news early, and following through on what you said you would do so people can rely on your word. In interviews this principle surfaces directly - tell me about a time you earned the trust of a skeptical team, or a time you had to deliver bad news - and as a quality threaded through almost every other story. Interviewers listen for whether you owned your part of a failure without deflecting, whether you were honest when honesty cost you something, and whether your behavior actually changed other people's willingness to depend on you. The strongest answers show trust being low, a specific action you took to rebuild it, and observable evidence that it worked.

What interviewers are evaluating

→Are you vocally self-critical - do you name your own mistakes plainly, or shade them into 'lessons learned' that blame circumstances?
→Do you deliver bad news early and directly, or sit on risks hoping they resolve themselves?
→Can you take direct feedback without defensiveness and act on it visibly?
→Do you follow through on commitments so colleagues can rely on your word?
→Did your action actually change someone's willingness to depend on you - is there observable evidence?
→Do you treat others with respect even during disagreement, conflict, or a postmortem?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you earned the trust of a skeptical stakeholder or team.
?Describe a time you had to deliver bad news to your manager or a customer.
?Tell me about a mistake you made and how you handled it.
?Give an example of when you received critical feedback - what did you do with it?
?Describe a time you had to rebuild a relationship after it broke down.
?Tell me about a time you were transparent about a risk even though it made you look bad.
?Describe a situation where you had to be candid with someone who outranked you.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: owning a data bug to a skeptical partner team

Prompt: "Tell me about a time you earned the trust of a skeptical stakeholder or team."

Situation: My service fed daily aggregated metrics to the analytics team, and they had stopped trusting our numbers after a previous engineer had quietly shipped a fix without telling them about a three-week window of bad data. They had started maintaining a shadow pipeline to double-check us, which cost them about a day a week.
Task: I had just taken over the pipeline and found a new defect - a timezone bug was double-counting roughly 4 percent of events near the UTC midnight boundary. My job was both to fix it and to repair a relationship where the partner team assumed we would hide problems.
Action: Instead of patching quietly, I messaged their lead the same morning I found it, before I had a fix, and laid out exactly which dates and which metric were affected and the estimated magnitude. I wrote a short root-cause doc, shared a backfill plan with dates, and invited their engineer to review my correction query before I ran it. Then I set up an automated daily reconciliation check between our output and their shadow pipeline and gave them the dashboard, so they could see drift themselves rather than take my word.
Result: The backfill corrected 11 days of history and the reconciliation check stayed green for the next four months. After about six weeks of clean numbers and visible reconciliation, they retired their shadow pipeline, reclaiming roughly a day a week of their engineer's time, and started routing new metric requests directly to us instead of building their own.

Why this works

What makes this strong: (1) the engineer chose transparency at a cost - reporting a bug before having a fix is the awkward, self-critical move the principle rewards; (2) trust is shown rebuilding with observable evidence (they retired the shadow pipeline); (3) it gives the other party verification (the reconciliation dashboard) rather than asking them to trust blindly; (4) concrete numbers anchor both the problem and the outcome.

STRONG

Strong: candid bad-news escalation on a slipping launch

Prompt: "Describe a time you were transparent about a risk even though it made you look bad."

Situation: I owned the backend for a feature launch that had been committed to a customer-facing date in an all-hands. Four weeks out, my load testing showed the new write path fell over at about 60 percent of the projected launch-day traffic because of lock contention I had underestimated when I scoped it.
Task: I had to decide whether to quietly grind on it and hope, or surface a credibility-damaging risk that I had partly caused by under-scoping the design.
Action: I escalated within a day. I brought my manager and the launch lead the load-test numbers, an honest statement that I had underestimated the contention in my original design, and three options with tradeoffs: slip two weeks for a proper fix, launch to 20 percent of traffic behind a flag, or launch on date with a known degraded-under-load risk. I recommended the staged 20 percent rollout and committed to specific re-architecture milestones with dates. I did not hide that the root cause was my design call.
Result: We did the staged rollout, hit zero contention incidents because we never exceeded safe load, and reached 100 percent two weeks later after I fixed the locking. My manager later told me the early, blunt escalation was why she kept giving me ambiguous, high-stakes work - the candor when it cost me bought more trust than a clean launch would have.

Why this works

What makes this strong: (1) it is vocally self-critical - the engineer names their own scoping mistake instead of blaming traffic estimates; (2) bad news is delivered early with data and options, not as a panic; (3) the payoff is explicitly about future trust (being handed harder work), which is what the principle measures; (4) specific load numbers and a concrete rollout plan keep it credible.

WEAK

Weak: vague 'people came to trust me' story

Prompt: "Tell me about a time you earned someone's trust."

Situation: When I joined my team, people did not really know me yet and I wanted to build trust with everyone.
Task: My goal was to become someone the team could rely on and respect.
Action: I worked really hard, I always tried to be honest and communicate well, and I made sure to deliver on my tasks. Over time people saw that I was dependable and they started coming to me with questions and trusting my judgment on things.
Result: Eventually I was seen as a trusted member of the team and people valued my opinion. It felt great to have earned that respect.

Why this is weak

Why this is weak: (1) there is no specific incident - 'I worked hard and was honest' is a personality claim, not a story; (2) no moment where trust was actually low or at risk, so nothing was earned against resistance; (3) zero self-criticism, which is the heart of this principle; (4) the result is a feeling ('it felt great') with no observable evidence anyone's behavior changed.

Common pitfalls

×Telling a 'people just came to trust me over time' story with no specific incident where trust was low or at risk.
×Avoiding self-criticism - the principle explicitly rewards being vocally self-critical, so an answer with no owned mistake falls flat.
×Framing a delayed disclosure as transparency: 'I told them once I had a fix' is not the same as surfacing bad news early.
×Deflecting the root cause onto circumstances, other teams, or bad estimates instead of owning your part.
×Claiming trust was rebuilt with no observable evidence - no behavior change, no metric, just 'they trusted me again'.
×Confusing being liked with being trusted; describing rapport-building when the question is about reliability and candor.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'why did you report it before you had a fix?' - explain that early honesty preserves the other party's ability to plan, and that hiding it would have cost more trust than the bug did.
→If asked 'how did you know trust was actually rebuilt?' - point to the concrete behavior change (they stopped double-checking you, gave you harder work, routed requests to you).
→If asked 'what was your part of the failure?' - answer it directly and specifically; refusing to name your contribution reads as the opposite of this principle.
→If asked 'how do you handle feedback you disagree with?' - show you separate hearing it from accepting it, and that you acted on the valid part visibly.
→If asked about a respectful-disagreement angle - bridge to Have Backbone, but keep the trust thread: candor delivered with respect.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Critical Feedback

General

Tested at every senior+ loop and every people-management interview. The signal is whether you deliver hard truths with care - or whether you avoid, soften beyond recognition, or wait for someone else to do it.

Companies that test this theme

Amazon

SDE II

Amazon

Senior SDE (L6 / SDE III)

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

Amazon LPFoundational Premium

Earn Trust (Amazon Leadership Principle)

Amazon's bar for how leaders build credibility: listen, speak candidly, treat others respectfully, and be vocally self-critical even when it is awkward.

About this theme

What interviewers are evaluating

→Are you vocally self-critical - do you name your own mistakes plainly, or shade them into 'lessons learned' that blame circumstances?
→Do you deliver bad news early and directly, or sit on risks hoping they resolve themselves?
→Can you take direct feedback without defensiveness and act on it visibly?
→Do you follow through on commitments so colleagues can rely on your word?
→Did your action actually change someone's willingness to depend on you - is there observable evidence?
→Do you treat others with respect even during disagreement, conflict, or a postmortem?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you earned the trust of a skeptical stakeholder or team.
?Describe a time you had to deliver bad news to your manager or a customer.
?Tell me about a mistake you made and how you handled it.
?Give an example of when you received critical feedback - what did you do with it?
?Describe a time you had to rebuild a relationship after it broke down.
?Tell me about a time you were transparent about a risk even though it made you look bad.
?Describe a situation where you had to be candid with someone who outranked you.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: owning a data bug to a skeptical partner team

Prompt: "Tell me about a time you earned the trust of a skeptical stakeholder or team."

Situation: My service fed daily aggregated metrics to the analytics team, and they had stopped trusting our numbers after a previous engineer had quietly shipped a fix without telling them about a three-week window of bad data. They had started maintaining a shadow pipeline to double-check us, which cost them about a day a week.
Task: I had just taken over the pipeline and found a new defect - a timezone bug was double-counting roughly 4 percent of events near the UTC midnight boundary. My job was both to fix it and to repair a relationship where the partner team assumed we would hide problems.
Action: Instead of patching quietly, I messaged their lead the same morning I found it, before I had a fix, and laid out exactly which dates and which metric were affected and the estimated magnitude. I wrote a short root-cause doc, shared a backfill plan with dates, and invited their engineer to review my correction query before I ran it. Then I set up an automated daily reconciliation check between our output and their shadow pipeline and gave them the dashboard, so they could see drift themselves rather than take my word.
Result: The backfill corrected 11 days of history and the reconciliation check stayed green for the next four months. After about six weeks of clean numbers and visible reconciliation, they retired their shadow pipeline, reclaiming roughly a day a week of their engineer's time, and started routing new metric requests directly to us instead of building their own.

Why this works

STRONG

Strong: candid bad-news escalation on a slipping launch

Prompt: "Describe a time you were transparent about a risk even though it made you look bad."

Situation: I owned the backend for a feature launch that had been committed to a customer-facing date in an all-hands. Four weeks out, my load testing showed the new write path fell over at about 60 percent of the projected launch-day traffic because of lock contention I had underestimated when I scoped it.
Task: I had to decide whether to quietly grind on it and hope, or surface a credibility-damaging risk that I had partly caused by under-scoping the design.
Action: I escalated within a day. I brought my manager and the launch lead the load-test numbers, an honest statement that I had underestimated the contention in my original design, and three options with tradeoffs: slip two weeks for a proper fix, launch to 20 percent of traffic behind a flag, or launch on date with a known degraded-under-load risk. I recommended the staged 20 percent rollout and committed to specific re-architecture milestones with dates. I did not hide that the root cause was my design call.
Result: We did the staged rollout, hit zero contention incidents because we never exceeded safe load, and reached 100 percent two weeks later after I fixed the locking. My manager later told me the early, blunt escalation was why she kept giving me ambiguous, high-stakes work - the candor when it cost me bought more trust than a clean launch would have.

Why this works

WEAK

Weak: vague 'people came to trust me' story

Prompt: "Tell me about a time you earned someone's trust."

Situation: When I joined my team, people did not really know me yet and I wanted to build trust with everyone.
Task: My goal was to become someone the team could rely on and respect.
Action: I worked really hard, I always tried to be honest and communicate well, and I made sure to deliver on my tasks. Over time people saw that I was dependable and they started coming to me with questions and trusting my judgment on things.
Result: Eventually I was seen as a trusted member of the team and people valued my opinion. It felt great to have earned that respect.

Why this is weak

Common pitfalls

×Telling a 'people just came to trust me over time' story with no specific incident where trust was low or at risk.
×Avoiding self-criticism - the principle explicitly rewards being vocally self-critical, so an answer with no owned mistake falls flat.
×Framing a delayed disclosure as transparency: 'I told them once I had a fix' is not the same as surfacing bad news early.
×Deflecting the root cause onto circumstances, other teams, or bad estimates instead of owning your part.
×Claiming trust was rebuilt with no observable evidence - no behavior change, no metric, just 'they trusted me again'.
×Confusing being liked with being trusted; describing rapport-building when the question is about reliability and candor.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'why did you report it before you had a fix?' - explain that early honesty preserves the other party's ability to plan, and that hiding it would have cost more trust than the bug did.
→If asked 'how did you know trust was actually rebuilt?' - point to the concrete behavior change (they stopped double-checking you, gave you harder work, routed requests to you).
→If asked 'what was your part of the failure?' - answer it directly and specifically; refusing to name your contribution reads as the opposite of this principle.
→If asked 'how do you handle feedback you disagree with?' - show you separate hearing it from accepting it, and that you acted on the valid part visibly.
→If asked about a respectful-disagreement angle - bridge to Have Backbone, but keep the trust thread: candor delivered with respect.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Critical Feedback

General

Companies that test this theme

Amazon

SDE II

Amazon

Senior SDE (L6 / SDE III)

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →