What do interviewers evaluate in Deliver Results questions?

Interviewers listen for signals like: Do you focus on the few key inputs that drive the outcome, or spread effort evenly across everything? Can you state the result as a number - the metric that moved, by how much, against what target? When you hit a setback, did you rise to it and still deliver, or did the goal quietly slip?

gitGood.dev

Amazon LPFoundational Premium

Deliver Results (Amazon Leadership Principle)

Amazon's outcome bar: focus on the key inputs, deliver them with the right quality and on time, and rise to the occasion when things get hard - never settle.

About this theme

Deliver Results is the principle that leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion, and that despite setbacks they rise to the occasion and never settle. It is the principle that punishes effort-without-outcome. For an engineer it is the difference between 'I worked really hard on it' and 'I shipped the thing that moved the metric'. It rewards identifying the few inputs that actually drive the outcome, removing blockers, and pushing through obstacles to a measurable finish line rather than producing activity. In interviews this principle is almost always evaluated through quantification. Interviewers want to hear what the goal was, what the key inputs were, what got in the way, and the number that proves you delivered. It is frequently paired with adversity - a setback you overcame to still hit the target. The weakest answers describe a lot of activity and end vaguely ('the project was a success'); the strongest ones name the metric, the obstacle, the specific moves you made, and the result that landed despite the obstacle.

What interviewers are evaluating

→Do you focus on the few key inputs that drive the outcome, or spread effort evenly across everything?
→Can you state the result as a number - the metric that moved, by how much, against what target?
→When you hit a setback, did you rise to it and still deliver, or did the goal quietly slip?
→Did you deliver with the right quality, not just fast - or did you cut corners that came back later?
→Did you remove your own blockers and drive to the finish, or wait to be unblocked?
→Is the result attributable to your specific actions, or just correlated with a team effort?

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 delivered a project under a tight deadline.
?Describe a time you overcame a significant obstacle to hit a goal.
?Give an example of a measurable result you are proud of and how you achieved it.
?Tell me about a time you had to prioritize ruthlessly to deliver on time.
?Describe a situation where a project was at risk and you turned it around.
?Tell me about a time you delivered despite limited information or shifting requirements.
?Give an example of when you pushed through after a major setback to still meet the bar.

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: salvaging a launch after a dependency slipped

Prompt: "Describe a time a project was at risk and you turned it around."

Situation: I owned the checkout-latency improvement that was a committed input to a quarterly conversion-rate goal - the target was cutting p95 checkout time from 2.1 seconds to under 1 second to lift conversion. Halfway through the quarter, the platform team that was supposed to deliver a new caching service told us it would slip by two months, and that service was the centerpiece of my plan.
Task: I still owned the under-1-second target for the quarter regardless of the dependency slipping. My job was to hit it without the cache I had planned around.
Action: I refocused on the inputs I could control. I profiled the checkout path end to end and found that 70 percent of the latency came from three synchronous downstream calls that did not need to be synchronous. I parallelized two of them and moved a non-critical fraud-scoring call to async post-confirmation, which I validated with the risk team so quality did not regress. I also added a small local in-process cache for a config lookup that was hitting the network on every request. I cut scope on a lower-impact tax-estimate optimization to protect the timeline. I shipped behind a flag and ramped over a week, watching conversion and error rates.
Result: p95 checkout dropped from 2.1 seconds to 0.85 seconds - under target - without the delayed caching service, and the conversion lift came in at 1.4 percent, which translated to a meaningful revenue number for the quarter. We delivered the committed input on time despite the dependency slip, and when the cache eventually landed it stacked on top for further headroom.

Why this works

What makes this strong: (1) the result is fully quantified against a stated target (2.1s to 0.85s, 1.4 percent conversion); (2) it shows rising to a setback - the key dependency slipped and the engineer delivered anyway by refocusing on controllable inputs; (3) quality is protected (validated the async fraud call with the risk team), so it is not corner-cutting; (4) ruthless prioritization is explicit (cut the tax-estimate work to protect the timeline).

STRONG

Strong: hitting a migration deadline by sequencing the key inputs

Prompt: "Tell me about a time you had to prioritize ruthlessly to deliver on time."

Situation: We had a hard six-week deadline to migrate 240 microservices off a deprecated internal auth library before it was shut off, or those services would start failing auth. When I picked it up, only about 30 services were done and the previous approach was hand-migrating each one, which would have taken roughly four months at that rate.
Task: I owned getting all 240 services migrated before the cutoff. Hand-migration was not going to make it, so I had to find the input that actually moved the number.
Action: Instead of grinding through services one by one, I focused on the highest-leverage input: I wrote a codemod that automated about 85 percent of the mechanical migration steps and a verification script that ran each migrated service's auth tests in CI. I triaged the remaining 210 services into three buckets - fully automatable, needs minor manual config, and genuinely custom - and got the automatable bulk done in the first two weeks. I personally took the dozen genuinely-custom services and paired with their owners. I sent a weekly burn-down to leadership so the deadline risk stayed visible.
Result: All 240 services were migrated four days before the cutoff with zero auth outages at shutoff. The codemod did the work that would have taken an estimated three engineer-months in about two engineer-weeks, and two other teams later reused it for their own deprecations. We delivered on a hard external deadline by investing in the one input - automation - that changed the math.

Why this works

What makes this strong: (1) it identifies the key input (automation) instead of just working harder at hand-migration; (2) the result is concrete and on a hard deadline (240 services, four days early, zero outages); (3) it quantifies the leverage (three engineer-months of work in two weeks); (4) it shows prioritization and triage, not undifferentiated effort.

WEAK

Weak: 'we worked hard and it was a success'

Prompt: "Tell me about a time you delivered a project under a tight deadline."

Situation: We had a big project with a tight deadline and a lot of moving parts, and everyone was under pressure to get it done.
Task: I was responsible for my part of it and making sure things came together.
Action: I put in a lot of hours, including some late nights and a weekend, and I coordinated with the other engineers to keep things moving. We pushed through all the obstacles and stayed focused on getting it across the line. It was a real team effort and everyone stepped up.
Result: We delivered the project on time and it was considered a big success. Leadership was happy with how it turned out and it felt great to have pulled it off.

Why this is weak

Why this is weak: (1) zero quantification - no metric, no target, no number that proves anything was delivered; (2) it celebrates effort and hours rather than outcome, which is exactly what this principle screens against; (3) the obstacles are abstract ('pushed through all the obstacles') with no specific setback overcome; (4) it is all 'we' and 'team effort', so nothing is attributable to the candidate's own decisions.

Common pitfalls

×Celebrating effort and hours ('I worked nights and weekends') instead of the outcome - this principle is about results, not activity.
×Ending vaguely ('it was a success', 'leadership was happy') with no metric, target, or number.
×Describing undifferentiated effort across everything rather than identifying the few key inputs that drove the result.
×Hitting the deadline by cutting quality that came back as incidents or rework - delivering with the wrong quality is not delivering.
×Using 'we' throughout so the result cannot be attributed to your specific decisions and actions.
×Telling a story with no setback - Deliver Results stories are strongest when you rose to a real obstacle and still landed the number.

Follow-up strategies

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

→If asked 'what was the result?' - lead with the number and the target it beat; never answer this one qualitatively.
→If asked 'what would you have done differently?' - point to an input you would have invested in earlier (e.g. automation, the profiling) rather than 'worked harder'.
→If asked about the setback - name it specifically and show the move you made to deliver despite it, not around it.
→If asked 'how did you prioritize?' - explain what you explicitly de-scoped or deferred to protect the key inputs and the deadline.
→If asked about quality - prove you did not cut corners by citing the validation, tests, or sign-off that protected the bar.

Related behavioral themes

Bias for Action

Amazon LP

Speed matters. But the principle is reversible-vs-irreversible reasoning, not 'I work fast.' Get this distinction wrong and the answer reads as reckless.

Ownership

Amazon LP

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

FREE

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

Deliver Results (Amazon Leadership Principle)

Amazon's outcome bar: focus on the key inputs, deliver them with the right quality and on time, and rise to the occasion when things get hard - never settle.

About this theme

What interviewers are evaluating

→Do you focus on the few key inputs that drive the outcome, or spread effort evenly across everything?
→Can you state the result as a number - the metric that moved, by how much, against what target?
→When you hit a setback, did you rise to it and still deliver, or did the goal quietly slip?
→Did you deliver with the right quality, not just fast - or did you cut corners that came back later?
→Did you remove your own blockers and drive to the finish, or wait to be unblocked?
→Is the result attributable to your specific actions, or just correlated with a team effort?

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 delivered a project under a tight deadline.
?Describe a time you overcame a significant obstacle to hit a goal.
?Give an example of a measurable result you are proud of and how you achieved it.
?Tell me about a time you had to prioritize ruthlessly to deliver on time.
?Describe a situation where a project was at risk and you turned it around.
?Tell me about a time you delivered despite limited information or shifting requirements.
?Give an example of when you pushed through after a major setback to still meet the bar.

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: salvaging a launch after a dependency slipped

Prompt: "Describe a time a project was at risk and you turned it around."

Situation: I owned the checkout-latency improvement that was a committed input to a quarterly conversion-rate goal - the target was cutting p95 checkout time from 2.1 seconds to under 1 second to lift conversion. Halfway through the quarter, the platform team that was supposed to deliver a new caching service told us it would slip by two months, and that service was the centerpiece of my plan.
Task: I still owned the under-1-second target for the quarter regardless of the dependency slipping. My job was to hit it without the cache I had planned around.
Action: I refocused on the inputs I could control. I profiled the checkout path end to end and found that 70 percent of the latency came from three synchronous downstream calls that did not need to be synchronous. I parallelized two of them and moved a non-critical fraud-scoring call to async post-confirmation, which I validated with the risk team so quality did not regress. I also added a small local in-process cache for a config lookup that was hitting the network on every request. I cut scope on a lower-impact tax-estimate optimization to protect the timeline. I shipped behind a flag and ramped over a week, watching conversion and error rates.
Result: p95 checkout dropped from 2.1 seconds to 0.85 seconds - under target - without the delayed caching service, and the conversion lift came in at 1.4 percent, which translated to a meaningful revenue number for the quarter. We delivered the committed input on time despite the dependency slip, and when the cache eventually landed it stacked on top for further headroom.

Why this works

STRONG

Strong: hitting a migration deadline by sequencing the key inputs

Prompt: "Tell me about a time you had to prioritize ruthlessly to deliver on time."

Situation: We had a hard six-week deadline to migrate 240 microservices off a deprecated internal auth library before it was shut off, or those services would start failing auth. When I picked it up, only about 30 services were done and the previous approach was hand-migrating each one, which would have taken roughly four months at that rate.
Task: I owned getting all 240 services migrated before the cutoff. Hand-migration was not going to make it, so I had to find the input that actually moved the number.
Action: Instead of grinding through services one by one, I focused on the highest-leverage input: I wrote a codemod that automated about 85 percent of the mechanical migration steps and a verification script that ran each migrated service's auth tests in CI. I triaged the remaining 210 services into three buckets - fully automatable, needs minor manual config, and genuinely custom - and got the automatable bulk done in the first two weeks. I personally took the dozen genuinely-custom services and paired with their owners. I sent a weekly burn-down to leadership so the deadline risk stayed visible.
Result: All 240 services were migrated four days before the cutoff with zero auth outages at shutoff. The codemod did the work that would have taken an estimated three engineer-months in about two engineer-weeks, and two other teams later reused it for their own deprecations. We delivered on a hard external deadline by investing in the one input - automation - that changed the math.

Why this works

WEAK

Weak: 'we worked hard and it was a success'

Prompt: "Tell me about a time you delivered a project under a tight deadline."

Situation: We had a big project with a tight deadline and a lot of moving parts, and everyone was under pressure to get it done.
Task: I was responsible for my part of it and making sure things came together.
Action: I put in a lot of hours, including some late nights and a weekend, and I coordinated with the other engineers to keep things moving. We pushed through all the obstacles and stayed focused on getting it across the line. It was a real team effort and everyone stepped up.
Result: We delivered the project on time and it was considered a big success. Leadership was happy with how it turned out and it felt great to have pulled it off.

Why this is weak

Common pitfalls

×Celebrating effort and hours ('I worked nights and weekends') instead of the outcome - this principle is about results, not activity.
×Ending vaguely ('it was a success', 'leadership was happy') with no metric, target, or number.
×Describing undifferentiated effort across everything rather than identifying the few key inputs that drove the result.
×Hitting the deadline by cutting quality that came back as incidents or rework - delivering with the wrong quality is not delivering.
×Using 'we' throughout so the result cannot be attributed to your specific decisions and actions.
×Telling a story with no setback - Deliver Results stories are strongest when you rose to a real obstacle and still landed the number.

Follow-up strategies

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

→If asked 'what was the result?' - lead with the number and the target it beat; never answer this one qualitatively.
→If asked 'what would you have done differently?' - point to an input you would have invested in earlier (e.g. automation, the profiling) rather than 'worked harder'.
→If asked about the setback - name it specifically and show the move you made to deliver despite it, not around it.
→If asked 'how did you prioritize?' - explain what you explicitly de-scoped or deferred to protect the key inputs and the deadline.
→If asked about quality - prove you did not cut corners by citing the validation, tests, or sign-off that protected the bar.

Related behavioral themes

Bias for Action

Amazon LP

Speed matters. But the principle is reversible-vs-irreversible reasoning, not 'I work fast.' Get this distinction wrong and the answer reads as reckless.

Ownership

Amazon LP

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

FREE

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 →