How to answer interview questions about Amazon leadership principle “Dive Deep”
The twelfth Amazon Leadership Principle is “Dive Deep.” If you’re preparing for an interview at Amazon, you should ask yourself what Amazon means by dive deep and how this leadership principle applies to your role at the company.
If you don’t know about the Amazon leadership principles, consider first reading this article about interviewing at Amazon.
How Amazon explains the “Dive Deep” leadership principle
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.
What does the “Dive Deep” Amazon leadership principle mean?
I think of this principle as being on a continuum with the “Bias for Action” leadership principle.
When you’re doing something, you first need to figure out what you’re doing (research and think, aka diving deep) and then you need to do it (aka acting).
Many people will tend to get stuck on one end of the spectrum. Many people are great at performing research but slow to act, and others will jump into action too quickly without making a plan.
In order to be good at something, you need to be good at both making a plan and acting on it. So in an interview, you want to be able to answer the “Dive Deep” questions and also the “Bias for Action” questions well, so that you paint a picture of yourself as someone who can make a plan and act on it (I cover how to answer the “Bias to Action” questions in another article).
A good “Bias” story will have a research phase and a good “Dive Deep” story will end in action.
A good “Dive Deep” should preferably include data borne of research. Here is an article about types of data you can include in these stories.
Telling “Dive Deep” stories like this might be easy for you if you’re a details person, as many people who have technical jobs are. It may not be easy for you if you’re a generalist or a big picture person. I personally tend to dislike talking about details, because I prefer talking about ideas or strategy. If I were going into an interview, I would need to add details about how I followed through on ideas. If you’re a big picture person, pay particular attention to your “Dive Deep” stories. On the other hand, if you’re someone who routinely digs into details, these questions are unlikely to be difficult for you because you’re always looking at data.
Ex-Amazon employee and blogger Dave Anderson summarizes the principle this way:
“Trust yet verify” is a favorite phrase at Amazon. We care deeply that leaders keep a careful eye on what they own, and know ways to audit their space. If something doesn’t make sense, our leaders need to have the ability (and interest) to dive in and figure out what’s going on. I love when I ask questions of people, and they can go four or five levels deep, and keep getting more excited because the details are actually interesting to them.”
Note the emphasis here on not just digging into the details, but getting excited about those details when you talk about them. If you re asked to speak to this principle in your interview, it’s not enough to list details – you need to use those details to demonstrate your enthusiasm for owning or contributing to a project.
Interview Questions Related to the “Dive Deep” Leadership Principle
If your interviewer asks about this leadership principle, she or he might ask one of the following questions:
Give me an example of when you used data to make a decision/solve a problem.
Tell me a time you gave insights beyond the data.
Have you ever leveraged data to develop strategy?
Tell me about a time you were trying to understand a problem on your team and you had to go down several layers to figure it out. Who did you talk with and what info proved most valuable? How did you use that info to help solve the problem?
Tell me about a problem you had to solve that required in-depth thought and analysis. How did you know you were focusing on the right things?
Walk me through a big problem in your organization that you helped to solve. How did you become aware of it? What info did you gather, what was missing, and how did you fill the gaps? Did you do a post mortem analysis and what did you learn?
Can you tell me about a specific metric you’ve used to identify a need for change in your department? Did you create the metric or was it readily available? How did this and other info influence the change?
How many stories do I need to prepare for each leadership principle?
Most people say that you should have two examples for each principle. That’s a good benchmark, but what if you get asked four Dive Deep questions? Will you have enough stories to answer them all?
In the onsite interview the interviewers will divide the principles up and each take two or three, so in one interview you may have more than two questions about a principle. What will you do if that happens?
I suggest that you practice using some questions you’ve developed for other principles to answer the Dive Deep questions. I think it’s a better idea to have a group of answers you can tailor for the different principles depending on what you get asked than preparing two for each principle.
How to Answer Questions Related to the “Dive Deep” Leadership Principle
Question: Tell me about a time you performed an analysis that that resulted in process improvements.
Answer given by a Systems Engineer
“The process for monthly mobile phone bill generation was slow. The bill generation process for one hundred and thirty thousand subscribers took twelve hours. I was asked to analyze whether there were opportunities to optimize the process.
Unfortunately, we had minimal documentation available on the process. I held a session with the application support engineers to understand how we could trace this process. After that, during the next bill cycle, we traced all database calls for twelve hours. Then I consolidated over a thousand trace files in chronological order and ran an Oracle profiler called tkprof.
My analysis revealed that the process spent lots of database time in performing single block reads and multiblock reads. The total time spent in doing I/Os was six hours. Approximately half of disk I/Os were taking more time than normal. After a similar analysis in preproduction, I saw that, even with 25% more subscribers, the bill run finished in the same time as production. The difference was that the preproduction environment had a newer CPU and a newer storage system. Part of the performance improvement in preprod was also the result of less traffic going into the preproduction environment. I/O took a lot less time in preprod.
After this analysis, I presented the findings in a twenty-six page report and a brief presentation. My recommendations were as follows:
Move bill run data to a dedicated database
Cache smaller tables in memory
Move bill run data to faster disks
As a result of my recommendations, we started the hardware modernization project, and as expected, newer CPUs and storage helped a lot. We were able to improve the performance of bill runs by approximately 35%. We brought down the bill run time from 18 to 12 hours. A big improvement, but I know I could make more progress.”
There are a lot of details in this answer from a Systems Engineer, but note how seamlessly he weaves in technical details to his story about a business process improvement. Even more importantly, note how he turns research into action. He “dives deep” but uses the information to make concrete recommendations, showing a “Bias for Action.” People tend to forget the “R” section of these answers – the results. Yes, the point is that you are great at doing research, but you still have to connect it to some action or your research was pointless. You don’t actually have to do the action yourself, but you can’t do the research and do nothing with it.
Question: Walk me through a big problem in your organization that you helped to solve. How did you become aware of it? What info did you gather, what was missing, and how did you fill the gaps?
Answer given by a Data Scientist
“There are different kinds of spam; it relates to the season. For example, there is a different kind during Christmas, the Super Bowl, the Oscars, etc. Spammers use campaigns to insert some kind of scam in text messages.
During the political campaigns last year, I was working on an assignment to detect spam in politics-related text messages. There is nothing wrong with doing campaign by text message, although it can be annoying, but the intention was to detect malicious messages within the body of these messages.
I started to analyze the data by isolating messages related to politics and then, once I had a good sample of these messages, I used data science and machine learning techniques to identify different patterns that could be not related to certain campaigns. I started by defining a base of target words which I will look for in the body of the message, and then I clustered together the most common words surrounding this base sample. It took me a very deep dive in the data to find common words that are used in a masked way, for example, one word separated by periods, numbers substituting for some words, etc. I could only do this by analyzing a lot of data.
At the end of the research, I tuned my code to automatically perform the analysis and deliver reports or alerts whenever this kind of spam was detected. To improve my detection analysis, I continued adjusting and fine-tuning my code as new results and/or patterns were discovered.”
This Data Scientist uses machine learning techniques to surface patterns to filter spam that would otherwise be difficult to catch. Note how diving deep into the data seems to come natural to her, as she tells her story.
To an interviewer at Amazon, you need to show that you’re not afraid to get into the details when the situation calls for it. I find when working with clients whose jobs revolve around data they don’t really have a problem finding stories to talk about they just have a problem giving proper context for their story, structuring the stories clearly, and remembering to connect the data to some kind of result or action.
