Amazon LPFoundational Premium

Learn and Be Curious (Amazon Leadership Principle)

Interviewers want self-driven learning that produced a concrete result - not a list of courses you took or technologies you've 'heard of.'

About this theme

Learn and Be Curious is one of Amazon's 16 Leadership Principles. It states that leaders are never done learning and always seek to improve themselves, that they are curious about new possibilities and act to explore them. The principle is about intellectual hunger applied with purpose: not collecting certificates, but noticing a gap or an interesting question and chasing it down until it produces something useful - a fix, a new capability, a better mental model that changes how you work. In interviews, this LP rewards stories where you taught yourself something outside your comfort zone because the problem demanded it, then applied it to real impact. Interviewers are wary of two weak patterns: the passive learner who lists trainings they sat through, and the curious-but-aimless engineer who learns for fun but never ships anything from it. They listen for a triggering question or gap, a deliberate effort to close it, and a concrete outcome. The best answers also show curiosity that spilled outward - you shared what you learned, or your digging uncovered a problem nobody had asked you to look at.

What interviewers are evaluating

→Was the learning self-driven, or just training your employer assigned you?
→Did curiosity lead to a concrete result, or was it learning for its own sake with no application?
→Did you step outside your comfort zone or established expertise to do it?
→Did a question or gap trigger the learning, showing you noticed something others missed?
→Did you share what you learned, multiplying its value beyond yourself?
→Do you keep learning continuously, or was this a one-off?

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 taught yourself a new skill or technology to solve a problem.
?Describe something you learned recently outside of your core job responsibilities.
?Tell me about a time your curiosity led you to discover or fix something.
?How do you stay current in a fast-changing field?
?Give an example of when you went deep on a topic you knew little about.
?Tell me about a time you learned something that changed how you approached your work.
?Describe a time you explored a new idea that others were not paying attention to.

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: Self-taught eBPF to crack an intermittent latency bug

Prompt: "Tell me about a time you taught yourself a new skill or technology to solve a problem."

Situation: We had an intermittent 200-millisecond latency spike on a core service that nobody could explain. Standard APM traces showed time disappearing 'somewhere in the kernel,' and the issue had been open as a low-priority ticket for four months because no one knew how to look deeper.
Task: I was not assigned this, but the spikes bothered me and were starting to breach our p99 SLO during peak. I decided to figure out where that kernel time actually went, which meant learning kernel-level tracing I had never touched.
Action: Over about two weeks of evenings and slack time I taught myself the basics of eBPF and bpftrace - read the docs, worked through a tutorial series, and wrote small probes on a test box first so I would not destabilize production. I then wrote a targeted bpftrace script to measure time spent in specific syscalls on the live service. The data showed the time was going into DNS resolution: our service was doing a synchronous lookup per request because a library was not caching results.
Result: I added a local DNS cache, which cut the p99 spike from 200 milliseconds to under 15 and closed the four-month-old ticket. I then wrote an internal wiki page and gave a 20-minute lunch-and-learn on using bpftrace for latency investigations; two other teams used the technique on their own mysteries over the next quarter.

Why this works

What makes this strong: (1) Self-driven - he picked up an unassigned, stale problem. (2) Stepped well outside his comfort zone (kernel tracing). (3) Concrete, quantified result that closed a long-standing issue. (4) Spread the knowledge - lunch-and-learn and wiki - so the curiosity multiplied beyond him.

STRONG

Strong: Dug into a billing line item and learned the pricing model

Prompt: "Tell me about a time your curiosity led you to discover or fix something."

Situation: I noticed our team's monthly cloud bill had a data-transfer line item that had quietly grown to about 8,000 dollars a month, roughly a third of our infra spend. Nobody owned cost, and the general assumption was that it was just the cost of doing business at our scale.
Task: It nagged at me that I did not actually understand what drove that number, so I set out to learn the provider's data-transfer pricing model in detail, which I had always treated as a black box.
Action: I spent a few days reading the provider's networking and pricing documentation closely - cross-AZ versus cross-region versus egress, NAT gateway processing charges, all the dimensions I had ignored. Then I enabled detailed flow logs and traced where the bytes were actually going. I found that a chatty internal service was talking to its database across availability zones on every call, racking up cross-AZ transfer charges, plus a large volume of logs egressing to a third-party tool.
Result: Co-locating the service with its database in one AZ and switching the log shipper to a compressed, batched transport cut that line item by about 70 percent, saving roughly 5,600 dollars a month. I documented the pricing gotchas I had learned in our team runbook so the next person would not treat transfer cost as a black box.

Why this works

What makes this strong: (1) Curiosity triggered by something he didn't understand, not an assigned task. (2) Went deep on a topic he had been avoiding (the pricing model). (3) Concrete dollar result. (4) Captured the learning in a runbook so it benefited the team.

WEAK

Weak: 'I'm always learning new things'

Prompt: "How do you stay current in a fast-changing field?"

Situation: I really like learning and I try to stay up to date with new technologies.
Task: I wanted to keep my skills fresh.
Action: I read a lot of blog posts and watched some online courses about new frameworks and tools. I also follow a bunch of people on social media and listen to tech podcasts.
Result: I feel like I know a lot about the latest technologies now and I'm always learning.

Why this is weak

Why this is weak: (1) Entirely passive consumption - reading and watching, never applying. (2) No triggering problem and no concrete outcome. (3) 'I know a lot' is self-assessment, not evidence. (4) Nothing was built, fixed, or shared; curiosity with no result is exactly the pattern interviewers screen out.

Common pitfalls

×Listing courses, certifications, or trainings you passively consumed instead of something you applied.
×Describing curiosity that never produced a concrete result - learning for its own sake with nothing shipped.
×Picking a 'learning' story that stayed inside your existing comfort zone, so there was no real stretch.
×Failing to name the trigger - the question or gap that made you go learn the thing.
×Keeping the knowledge to yourself when you could have shared it and multiplied the value.
×Vague self-assessment ('I know a lot now') with no metric, artifact, or downstream impact.

Follow-up strategies

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

→If asked 'What triggered the learning?' - point to the specific gap or question, showing it was self-driven curiosity, not an assignment.
→If asked 'How did you apply it?' - tie the new skill directly to a measurable outcome (latency, dollars, a closed ticket).
→If asked 'How do you stay current?' - give a concrete recent example of something you learned and shipped, not a list of podcasts.
→If asked 'Who else benefited?' - describe how you shared it (doc, lunch-and-learn, runbook) to show the curiosity scaled.
→If pushed on time, be honest that you used slack time and de-risked on a test environment first - this shows judgment alongside curiosity.

Related behavioral themes

Dive Deep

Amazon LP

Leaders operate at all levels. The interviewer is testing whether you actually understand your own systems - or whether you summarize what your team built.

Invent and Simplify

Amazon LP

Interviewers want proof you removed complexity, not just added a clever feature. The 'Simplify' half is what most candidates miss.

Companies that test this theme

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 →

About this theme

What interviewers are evaluating

→Was the learning self-driven, or just training your employer assigned you?

→Did curiosity lead to a concrete result, or was it learning for its own sake with no application?

→Did you step outside your comfort zone or established expertise to do it?

→Did a question or gap trigger the learning, showing you noticed something others missed?

→Did you share what you learned, multiplying its value beyond yourself?

→Do you keep learning continuously, or was this a one-off?

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 taught yourself a new skill or technology to solve a problem.

?Describe something you learned recently outside of your core job responsibilities.

?Tell me about a time your curiosity led you to discover or fix something.

?How do you stay current in a fast-changing field?

?Give an example of when you went deep on a topic you knew little about.

?Tell me about a time you learned something that changed how you approached your work.

?Describe a time you explored a new idea that others were not paying attention to.

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: Self-taught eBPF to crack an intermittent latency bug

Prompt: "Tell me about a time you taught yourself a new skill or technology to solve a problem."

Situation: We had an intermittent 200-millisecond latency spike on a core service that nobody could explain. Standard APM traces showed time disappearing 'somewhere in the kernel,' and the issue had been open as a low-priority ticket for four months because no one knew how to look deeper.
Task: I was not assigned this, but the spikes bothered me and were starting to breach our p99 SLO during peak. I decided to figure out where that kernel time actually went, which meant learning kernel-level tracing I had never touched.
Action: Over about two weeks of evenings and slack time I taught myself the basics of eBPF and bpftrace - read the docs, worked through a tutorial series, and wrote small probes on a test box first so I would not destabilize production. I then wrote a targeted bpftrace script to measure time spent in specific syscalls on the live service. The data showed the time was going into DNS resolution: our service was doing a synchronous lookup per request because a library was not caching results.
Result: I added a local DNS cache, which cut the p99 spike from 200 milliseconds to under 15 and closed the four-month-old ticket. I then wrote an internal wiki page and gave a 20-minute lunch-and-learn on using bpftrace for latency investigations; two other teams used the technique on their own mysteries over the next quarter.

Why this works

STRONG

Strong: Dug into a billing line item and learned the pricing model

Prompt: "Tell me about a time your curiosity led you to discover or fix something."

Situation: I noticed our team's monthly cloud bill had a data-transfer line item that had quietly grown to about 8,000 dollars a month, roughly a third of our infra spend. Nobody owned cost, and the general assumption was that it was just the cost of doing business at our scale.
Task: It nagged at me that I did not actually understand what drove that number, so I set out to learn the provider's data-transfer pricing model in detail, which I had always treated as a black box.
Action: I spent a few days reading the provider's networking and pricing documentation closely - cross-AZ versus cross-region versus egress, NAT gateway processing charges, all the dimensions I had ignored. Then I enabled detailed flow logs and traced where the bytes were actually going. I found that a chatty internal service was talking to its database across availability zones on every call, racking up cross-AZ transfer charges, plus a large volume of logs egressing to a third-party tool.
Result: Co-locating the service with its database in one AZ and switching the log shipper to a compressed, batched transport cut that line item by about 70 percent, saving roughly 5,600 dollars a month. I documented the pricing gotchas I had learned in our team runbook so the next person would not treat transfer cost as a black box.

Why this works

WEAK

Weak: 'I'm always learning new things'

Prompt: "How do you stay current in a fast-changing field?"

Situation: I really like learning and I try to stay up to date with new technologies.
Task: I wanted to keep my skills fresh.
Action: I read a lot of blog posts and watched some online courses about new frameworks and tools. I also follow a bunch of people on social media and listen to tech podcasts.
Result: I feel like I know a lot about the latest technologies now and I'm always learning.

Why this is weak

Common pitfalls

×Listing courses, certifications, or trainings you passively consumed instead of something you applied.

×Describing curiosity that never produced a concrete result - learning for its own sake with nothing shipped.

×Picking a 'learning' story that stayed inside your existing comfort zone, so there was no real stretch.

×Failing to name the trigger - the question or gap that made you go learn the thing.

×Keeping the knowledge to yourself when you could have shared it and multiplied the value.

×Vague self-assessment ('I know a lot now') with no metric, artifact, or downstream impact.

Follow-up strategies

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

→If asked 'What triggered the learning?' - point to the specific gap or question, showing it was self-driven curiosity, not an assignment.

→If asked 'How did you apply it?' - tie the new skill directly to a measurable outcome (latency, dollars, a closed ticket).

→If asked 'How do you stay current?' - give a concrete recent example of something you learned and shipped, not a list of podcasts.

→If asked 'Who else benefited?' - describe how you shared it (doc, lunch-and-learn, runbook) to show the curiosity scaled.

→If pushed on time, be honest that you used slack time and de-risked on a test environment first - this shows judgment alongside curiosity.