The Bar Raiser Interview — Amazon LP - Deliver Results

DISCLAIMER: All interview questions used here are already available publicly from sites like Glassdoor and other blogs. I will not be providing any "special" or "confidential" questions from Amazon, so if that's why you are here, sorry, but you can close this right away. All opinions, aLpHaBeTs, punctuation; and grammar here are my own and do not represent my employer.

Delivering these will take no time!

Deliver Results: Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Interestingly, the Amazon Jobs website lists Deliver Results as the final competency on the list. So obviously the first Leadership Principle that I wanted to start talking about is Deliver Results ;)

Why start with this? Because I just find so many people misunderstand this principle and think it means something it most likely does not.

Let's start with a typical Deliver Results question like so:

Q: Tell me about a time where you worked against tight deadlines. What did you do to make sure you delivered on time?

Now, let's look at a typical Candidate response when faced with that question:

A: I made sure that I worked on evenings and weekends to make sure the timelines were met. It was a difficult 3 weeks, but the feature was super critical to the customer and so I did my best to deliver this.

The Candidate worked extra hard to deliver the right result for the customer. Pretty good, right?

Well, not quite, we have no data on raising the bar here. Why?

Let's see what the missing bits are in this situation:

• The Candidate worked evenings and weekends. In other words, worked more than 3 weeks to get it delivered in 3 weeks.
• It's not clear if the Candidate ever questioned the timelines.

So let's go ahead and ask the Candidate about timelines again:

Q: Why were the timelines fixed? Did you talk to stakeholders about moving the timelines?
A: No, I didn't question the timelines since it was given to me by my manager.

Ooof. Sorry to tell you my dear reader, but that does not raise the bar. It directly violates the first part of the principle: Leaders focus on the key inputs for their business. If you are not questioning the inputs and validating that we are doing the right thing, what is the point in even doing it?

Delivering results isn't about working hard. It's about working smart and getting things done.

But BR, what if it really was fixed timelines?

Ok, let's try that:

Q: Why were the timelines fixed? Did you talk to stakeholders about moving the timelines?
A: Yes, but since this was a regulatory requirement, there wasn't much we could do to change the timeline.

Ok, better, that definitely counts as a setback as mentioned in the principle. Still not bar-raising though, so let's ask more questions and see if we can get a good response:

Q: Ok, so the date couldn't be moved. What did you do to make sure you hit the deadline?
A: I asked my manager for extra resources to make sure we hit the deadline.

Sweet! So we tried to work smarter to hit the goal by asking for more resources. Surely that must be bar-raising?

Well, not quite. Depending on what level you were interviewing for, it could still be just meeting the bar.

I hear you thinking:

But BR! You can't keep moving the goalpost like that. Tell me how does it matter what level I am interviewing for?

Ok, here is my best attempt to make this clear without divulging any internal specific details:

1. L3/L4 - "The noob" - These are considered entry-level jobs for relatively inexperienced folks. These could be people who are just out of school, are switching job families, or are coming back to work after a gap.
   So for these levels, if you raised a concern with deadlines or asked for additional resources to make sure a project gets completed, there is a 7/10 chance that it not only meets the bar but might even raise it.

2. L5 - "The Intermediate aka Limbo stage" - This is the "I am no longer a new hire" but "I am not yet a senior" position. People in these roles are typically expected to not need direction to work on defined solutions to problems, but still need guidance on coming up with solutions to problems. So the response above fits in with "I asked for clarity and help, but I didn't do anything beyond that". That translates to a "Meets" in my book about 5/10 of the time. There are times where this might not be a "meets", e.g. Candidate needed prodding from manager to ask these, or someone else was leading the project and asked for extra resources, etc.

3. L6 - "The Senior" - This is considered a senior position for most job families, and is the first level that has the word "Senior" in the title. Woo! This is also considered a level where people can work autonomously without any direction needed to solve a problem. They might still need guidance on handling or influencing cross-team initiatives but are more often than not very capable of handling things on their own. If you stopped with the above response for an L6 level, there's a high chance (8/10) that you might not meet the bar, let alone raise.

4. L7+ - If you were interviewing with Amazon for L7, there's a pretty high chance you aren't reading this. If you still need data around this, hit me up and I will be more than happy to update this section :D

So, getting back to the example, what is an example of something that truly raised the bar, regardless of level?

Q: Why were the timelines fixed? Did you talk to stakeholders about moving the timelines?
A: Yes, but since this was a regulatory requirement, there wasn't much we could do to change the timeline.
Q: Ok, so the date couldn't be moved. What did you do to make sure you hit the deadline?
A: I asked my manager for extra resources to make sure we hit the deadline, but we didn't have anyone else to pick this up.
Q: Ok, so what other strategies did you use?
A: So the first thing I did was to figure out which parts of the deliverables could be cut down. I noticed that we could get an MVP version out in 4 weeks. Once I had the subset validated by stakeholders, I then worked on optimizing the other aspects of launching a feature.

I realized that since this was a feature on an existing system, we would be ok with testing only the new feature and its integration with the system, and depend on the regression tests to catch any additional issues instead of spending 2 weeks on manual E2E testing. So that cut down a week of effort, putting us squarely at 3 weeks. I further made sure that all stakeholders including my manager and product teams were aware of what we committed to and where we were with delivery.

Once we got closer to the delivery date, we had a go/no-go meeting every week to see where we stood and what things we needed to re-prioritize to get the product out the door. Before the launch, I helped my team write documentation and SOPs (Standard Operating Procedures) to handle any failures we might face.

The week of launch, I made sure that our metrics were set up to track any failures. Since we had compromised on testing, it was important to track metrics to make sure nothing was off. This would allow us to launch with a high amount of confidence that things would work as intended. Once we launched successfully, I ensured that my team went back and wrote those additional tests.

Whoa, Whoa, WHOA. Slow down a bit BR, what is all this stuff that I have never heard of before?

Ok, let's step back and see what all this Candidate did:

• They raised a flag that timelines are hard to hit.
• They asked for resources.
• They tried to reduce the scope and cut down on work. Further, they tried to optimize existing processes and leverage those to deliver faster.
• They kept everyone informed.
• They constantly re-prioritized according to the changes in the situation.
• They had a mitigation plan in case everything failed and they had a way to track it.
• They went back and fixed their shortcuts so that they didn't always have to depend on alternative ways to catch failures

Let's see what all checkboxes they ticked:
✅ Leaders focus on the key inputs for their business - Yup, they checked this for sure.
✅ Deliver them with the right quality - Notice that they delivered the right quality, sure it wasn't the perfect quality you expect, but they made this trade-off consciously and went back and fixed it.
✅ in a timely fashion - Yup, hit the dates, sure they dropped a couple of features, but everyone, including the customer, was happy.
✅ Despite setbacks, they rise to the occasion and never settle. - Yup, they definitely rose to the challenge and made sure they resolved the key risks and deliver on time.

They ticked all the checkboxes and then some. That, my dear reader, is truly bar-raising for this question.

Delivery always matters. Because customers always want things yesterday. Yesterday!

---

So how do I prepare for the Leadership Principle - Deliver Results?

Ok, so we saw what a bar-raising example looks like for that particular question. But what about other questions? Surely I cannot write a blog post for every (20+) question that Amazon asks a Candidate for Deliver Results?

You are right. And that is not even the purpose of this post.

The purpose of this blog series is not to prepare you for an interview, it is to get you prepared to be a top-notch employee at Amazon who can be successful there long-term.

So what can we do to get there? First, let's focus on the interview part. A good first step is writing down the things that stopped or slowed you from delivering a project. Examples of these might be:

1. Issues with timelines - Unrealistic timelines, sudden changes in timelines, etc.
2. Resourcing shortages - Your boss went on vacay, your co-worker got married, your other co-worker went scuba diving for 5 weeks, etc.
3. Scope creep - customers suddenly need a hundred other things
4. Miscommunication during projects
5. Customers not being accommodative
6. Missing tools or systems to execute your tasks - a missing saw, broken computer, cord system not accurate, etc.

Then start thinking about what you did to solve each of those. Similar to our bar-raising Candidate, think of:

• Raising flags when something is not going to get done
• Re-prioritizing goals and resources.
• Reducing the scope and optimizing existing processes.
• Leveraging existing things - standing on the shoulders of giants.
• Communicating. Constantly.
• Coming up with a mitigation plan for the risks.
• Going back and improving processes so that the next time the thing that stopped/slowed you down does not happen again.

If you cannot think of situations where these things happened or where you handled them well, it might be a good idea to start using these to guide you during your next project so that you see how these help in improving the quality of your projects. This is normal for folks who are interviewing for L3/L4/L5 since they might not have much industry experience. Start applying these principles at your current workplace and you will notice that it drastically increases your value to the company.

So, that's it folks. Deliver Results is easy enough to showcase and raise the bar if you have done the right things at your current job. Even if not, start practicing some of what you learned today so that you can apply these at your current job and get even better at it.

Good luck with your Amazon Interview!

Sincerely,
The Bar Raiser.

---

But.. how do I raise the bar for other LPs or functional competencies?

That’s what this entire series of articles is about. In each article in this series, we focus on a specific LP or functional competency where I will dive deep into what each of them means and what it takes to raise the bar for a given Leadership Principle or competency.

I also fully intend to write about Bar raising for technical roles, including, but not limited to, SDEs, FEEs, WDEs, Data Engineers, Data Scientists, Applied Scientists, Database Engineers, Performance Engineers, and BI Engineers. So stay tuned!

P.S: If you want another take about interviewing with Amazon and learn more about the Leadership Principles, Dave Anderson has an excellent article describing those in-depth.

P.S.2: The hoodie image was found on Amazon.com and is in no way affiliated with me or Amazon afaik. I just happen to randomly own one ;)