general

Amazon Earn Trust: Meaning, Examples and Interview Questions

Earn Trust is the Amazon leadership principle candidates most often misread. It sounds like "be reliable and pleasant", so people bring a story about keeping a promise and wonder why the interviewer looked unconvinced. At Amazon, Earn Trust is mostly about candor: saying the uncomfortable thing, admitting the mistake before anyone finds it, and listening long enough to be changed by what you hear.

Interviewers test it because trust is what lets a company of Amazon's size move without a committee behind every decision. An engineer who hides a bad metric, or a manager who cannot give a direct report honest feedback, costs the team far more than the original slip.

This guide covers the official wording, what the principle looks like day to day, examples from engineering and non-engineering roles, 14 interview questions, a worked STAR answer, and the follow-up questions you should expect.

The official wording from Amazon

Leaders listen attentively, speak candidly, and treat others respectfully.

That is the opening sentence of the principle on Amazon's leadership principles page. The rest of the text asks leaders to be vocally self-critical even when it is awkward, to resist believing their own team is better than it is, and to benchmark themselves against the best.

Read the three verbs in order: listen, then speak, then treat. Candor without listening is just volume. Respect without candor is politeness, and politeness does not earn trust at Amazon; it postpones the hard conversation.

What Earn Trust means in practice

You raise bad news early and yourself. A slipped date announced on Monday earns trust; the same slip discovered by your manager on Friday destroys it.
You are specific about what you got wrong. "The estimate was off" is a shrug. "I assumed the API was idempotent and did not check" is self-criticism someone can act on.
You disagree in the room, not in the hallway afterwards. Trust is built by people who say the same thing to your face and behind your back.
You keep commitments small enough to be visible. Three kept promises a week beat one heroic quarter.
You give credit by name and take blame by name. "We" is fine in a retrospective; it is evasive in an interview.
You change your mind out loud. Saying "you were right, I was wrong, here is what I am doing differently" is the fastest trust-building sentence in any workplace.

Earn Trust examples at work

The engineer who flagged their own outage. A backend engineer ships a config change that doubles p99 latency for one region. Monitoring has not alerted yet. She posts in the team channel: what changed, what she sees, what she is rolling back, and when she will confirm. The incident is minor. The post is remembered for a year, because it told everyone what she does when nobody is watching.

The analyst who distrusted a good number. A data analyst finds that a new checkout flow lifted conversion by 9 percent. Instead of presenting it, he spends a day trying to break the result and finds a tracking change that double-counted one segment. The real lift is 2 percent. He presents both numbers and how he got from one to the other. The product lead starts asking for his read on every experiment.

The product manager who said no with reasons. A sales director asks for a feature "a big customer needs". The PM lists what it would displace, asks for the customer call recording, listens to it, and comes back with a smaller change that solves the customer's actual problem. The director disagreed at first and now routes requests through her because she tells him what she really thinks.

The support lead who owned the policy. A customer support team lead inherits a refund rule that frustrates customers. Instead of blaming "policy", she measures how many contacts it causes, writes a one-page proposal, and tells her team the honest timeline for a change. Contacts about the rule drop because agents stop apologizing for something they can now explain.

Earn Trust interview questions

Amazon interviewers rarely say the words "earn trust". They ask for a story, then check whether your behavior matched the principle. These are the questions that show up most.

Direct questions

Tell me about a critical piece of feedback you received. What did you do with it?
Give an example of a time when you were not able to meet a commitment to a team member. What prevented it, and what did you do?
Describe a time you had to deliver bad news to your manager or a stakeholder.
Tell me about a time you were wrong in front of your team. How did you handle it?
How did you earn the trust of a new team or client quickly?
Tell me about a time you had to rebuild trust after a mistake.
Give me an example of building a trusting working relationship with someone who did not want to work with you.

Questions that test it indirectly

How do you like to receive feedback from coworkers or managers?
Tell me about a time your team's goals were misaligned with another team's. How did you resolve it?
How do you convince someone who resists what you are proposing?
Tell me about a time you discovered a problem that nobody else had noticed. Who did you tell, and when?
Describe a time you took credit or blame that was not entirely yours. What happened?
Tell me about a time you disagreed with your manager. What did you say, and what did you do afterwards?
When did you last change your mind because of something a junior colleague said?

A sample STAR answer

Question: tell me about a critical piece of feedback you received.

Situation. In my second year as an engineer I led the migration of our notification service to a new queue. Two months in, my manager told me in a one-on-one that two teammates felt I was reviewing their pull requests as if I was the only one who understood the system, and that one of them had started sending work to another reviewer to avoid me.

Task. I had to fix the working relationship without slowing the migration, which was already on a tight date, and without making the teammates feel they had been reported.

Action. I asked my manager for the specific comments that landed badly and read them again that evening. Three of them were correct on the code and wrong in tone; two were me rewriting a design choice in a review comment instead of raising it in planning. The next day I told the team, in our standup, that the feedback was accurate and what I would change: design disagreements go to a 15-minute call, review comments get a reason and a suggested fix, and I would ask one of the two teammates to review my next three PRs. I also set up a shared review checklist so the standard lived in a document instead of in my head.

Result. Both teammates reviewed my work the following sprint, and the one who had been avoiding me paired with me on the hardest part of the cutover. We delivered the migration one week late instead of the three weeks my manager had feared. In my next review, "approachable reviewer" was listed as a strength, with the same two people as the source.

Why this answer works

It names a mistake precisely (tone, and design decisions made in the wrong forum) instead of a vague "I could communicate better".
The self-criticism is vocal: the correction happened in front of the team, which is what the principle asks for.
The result includes a number, a date, and evidence from the people who gave the feedback, not just a feeling that things improved.

What the interviewer probes next

A good Earn Trust story invites follow-ups. Expect at least three of these:

"What exactly did the feedback say?" The interviewer wants the uncomfortable detail. If you soften it, they will assume you did not fully accept it.
"What was your part versus the team's?" Keep your "I" and "we" honest. A story where the team fixed everything says nothing about you.
"How do you know trust was actually rebuilt?" Have evidence: who came back to work with you, what changed in review or in the next performance cycle.
"What would you do differently?" There is always something. Having no answer reads as a lack of self-criticism, which is the opposite of the principle.
"Did you ever disagree with the feedback?" It is fine to have pushed back on one point, as long as you can show you listened first and changed what was fair.

Common mistakes

Choosing a safe story. "I always deliver on time" is not an Earn Trust story. The principle is tested through something that went wrong.
Blaming the other party. A story where trust broke because the other person was unreasonable will be scored against you, even if it is true.
Treating candor as bluntness. Amazon wants candid and respectful. A story about telling someone off is not the same as giving hard feedback well.
Skipping the listening half. Many candidates describe what they said and nothing about what they heard. Show the moment you changed your view.
Ending without a measurable result. "Things got better" is not a result. Who worked with you again, what did the next review say, what number moved.
Confusing it with Deliver Results. Keeping a promise is part of trust, but the interviewer scores the candor and the self-criticism, not the delivery.

Related leadership principles

Have Backbone; Disagree and Commit is the other half of candor: trust lets you disagree without the relationship breaking.
Dive Deep supplies the facts that make candid feedback credible rather than merely confident.
Customer Obsession applies the same principle outward: customers trust a company that tells them the truth about delays and defects.

The full list, with questions for each principle, is in our Amazon leadership principles guide. Structure every story with the STAR method and keep them in a story bank so you can pull the right one under pressure.

Want someone who has run Amazon loops to pressure-test your Earn Trust stories? Get matched with a coach, then work through Have Backbone; Disagree and Commit and Dive Deep next.