First of all, AWS interviews are not as difficult as many other companies in the same league, e.g. Google or Facebook. That being said, it is thorough and tiring.
Once you have the rules figured out, it will be much easier for you to prepare and pass. So let’s dive right in!
The process is simply broken into three parts.
- The Phone Screen. Very basic background check.
- The Homework. After preliminary phone screen, depending on the position you apply, you may get a homework. You will need to finish it and present it. This is the easy part.
- The Interviews. Also known as assessments. No stupid and personal questions, everything is related the the leadership principles (see below). This is not difficult if you have prepared in advance according to the principles, but will be very, very tiresome as most interviews happen within a single day and it will be 2-7 rounds (usually 4), each lasting 1 hour.
This is usually a senior member from a different unit than the one you were applying for. Bar riser will try to push your limits. Stay cool.
You need to be comfortable articulating your ideas using a whiteboard.
The Prima Dogma
The interview is highly mechanical, with a large pool of preset questions. It is so mechanical that I think in near future it could be handled by Chatbots.
The reasons behind the mechanical nature are as follows.
- The interview process is highly standardized, quantified and scoped
- It is wholly based on the 12 Leadership Principles
So before we dive into the principals, let’s answer the top questions: NO BRAINTEASERS!
Unlike Google, which is notably keen on using those stupid brainteasers in interviews, AWS has found brainteasers uncorrelated to performance and are difficult to measure, so they are totally removed from the process.
Since everything is focused on the Leadership Principles, it is safe to say that if and when you fully understand them and put your experiences into the buckets then the non-technical part of your interview (which is considerably more difficult than the technical part) will have no problems.
Let’s dive into the Leadership Principles.
This is ultimately THE most important one. Amazon and AWS are claimed to have thrived totally based on this principle.
While for many other principles you need find corresponding stories, this one has to stay through all your stories. You need to prove everything you do, you do out of caring your customers.
Be prepared to answer follow-up questions like:
- What does this have to do with your customer?
- What is the impact of your customer?
- How does this connect to your customer?
- What is the value to the customer?
- What is the main challenge of your customer?
- What is the response from your customer?
Also try the Working Backwards method by AWS. Or the Lean Startup. Whatever you want to call it.
Basically you start with a customer problem (a very short statement), then you create some mockup (like a news press article, fake launch announcement) and show the customer trying to see whether this has value. When value is validated you going to start an MVP (like manually response to customer emails) to implement that value. Grow from there, as customers throw more problems, you solve them one by one.
Yes this is a “leadership” principle, and Amazon says it wants everybody to be a leader. So ownership is fairly important.
Ownership is another word for “proactive”. You need to prove that you are fully committed to what you were trying to do, actively solve problems and seek resources to help.
Ownership include two things: first, a clear target; second, the steps to make it happen. You need to understand what you want to achieve, take every step needed, find every resource required to make it happen.
Do not ever think that “there are boundaries regarding responsibilities”, or “I delegate this part completely to someone else”. You may seek for help, but still you check the results, adjust as needed, and own the target.
Invent and Simplify
Honestly, this is a less important principle. You can solve a problem in a ingenious way, or you may solve it a traditional way. Former gets a plus, but later does not impose a penalty.
As long as you stay focused on your customer, you do not HAVE TO invent.
Anyway, if you did have some good stories to share, go and share it. Decorate your stories with inventions and simplifications. Just don’t overthink about it. Amazon is not like Google.
Are Right, A Lot
This one is controversial and due to different interpretations.
Amazon thinks that leaders act in a timely manner, thus less thinking and reasoning time. Or probably the environment was so ambiguous but immediate decisions were needed.
So, you better have good instincts, and be proven right for most of the time.
Find stories that show your instincts and the will the make bold decisions. Find stories that have good ending and prove you right.
However, also find stories that show your “scientific side”. Like being a total skeptic, trying to disconfirm everything you see, only to find the true logic of something, and build your instincts along the way.
Anyway, this is a pretty subjective principle, so don’t sweat it.
Learn and Be Curious
You should display characteristics of a continued learner.
AWS has hundreds of services, and the number’s growing non-stop. You need to keep up with things.
Also as the Cloud abstract many things away, techies are not all that techy anymore. Also business developers need to understand the mechanism of the Cloud, as well as diving deep into customer business. So, show your are will to learn and understand things that were usually not in your domain. Or better, show that you are highly cross-functional.
Find stories that directly connect to your work. Not something like I recently read a book, or I learn drawing in my spare time. Find things that help your work, that boost some figures, that solve problems and that show your ability to always be up-to-date.
Hire and Develop the Best
As you are a leader, you are expected to hire or at least help others grow. This is a clear one. Just find cases you identify, develop or hire someone who is very talented in some way.
Insist on the Highest Standards
This one is easy. Find stories that show there were a few options, and you picked the one with highest standards.
By “highest standard”, it means this option is the best one for your customer. Although it may require extra efforts, time and money.
Also find stories that show you are unwilling to greenlight something that is not up to your standard.
This is where you let your thoughts wander.
You will show that you dare to think about the best-in-best cases. The happiest path a customer could go with you.
Lots of good business, huge upscale, good sales, perfect relationship, sky-rocketing numbers.
Think whatever you dare to think.
Also, try to think horizontally.
- Are there any other ways you may serve your customer?
- Are there something you neglected in previous engagements?
- Are there more things we could do together?
- Can we bring more players and resources into the relationship and make it a multi-win?
Bias for Action
The previous principles were more about talking and thinking. This one is more on how you act and respond quickly, instead of struggling to find the perfect solution.
You should show that you make quick feedback loops by acting quickly, collect feedback, then act again. Not you made thorough plan for a long time, making sure everything is smooth.
Also show that you are do things in a hands-on manner. Not lots of logics and analysis part, but more about the real world processes, steps, obstacles, challenges, the details of how you approach problems.
Be aware. This is NOT about how you cut your cost and spend less money on your business trip. It is more in the sense of the Lean Startup.
Although you may Think Big and have a super big plan, start small. Start self-sufficient, without requiring unnecessary resources.
Most AWS projects start with a very small and working pilot that costs virtually nothing. Seeds may grow slowly and become big sprouts but on Day 1, you start small, start frugal.
This one is pretty self-explanatory. People have to trust you for you to lead and affect them.
You earn trust by the following.
- Show your skills, be the best in your field
- Give useful opinions, ones that were important but missed by your teammates
- Care your customer, think one step further for your customer so they will count you as one of them
- Meet expectations, meet your commitment
- Develop people, train them, share your experience
In Cloud business most things are abstracted. Many people may stay superficial above those abstractions. As a part of a big Cloud, you need to dive deep under the surface.
Be prepared to be asked in quick succession manner down to the most detail part of something. Do not worry, most of the time it is only to check how deep you have dived, not about verifying your knowledge.
For example, if you were asked about loading a Web page, it may go like, what happen in the first second after you type a domain and hit Enter key, browser stuff, HTTP stuff, public key algorithms, DNS, TCP/IP, BGP, packets, routers, CRC, bytes, bits…endless. This is not about testing your knowledge, but to see how deep you may dive.
The same for business.
It is usual for people from consulting firms to understand something about almost everything, enough to have professional conversations, but in the context of this principle, you will always need to have something that you know down to very details.
That being said, do not overdo it. You don’t need to know what the 3rd round of a DES algorithm do, just dive to a level you feel confident and comfortable.
Have Backbone; Disagree and Commit
You will want to show Amicus Plato, sed magis amica veritas.
You may disagree with some decisions by your superior, your peer or even customer. You should try to think carefully and take your stand.
Even if you failed to do so, you still maintain your ownership and professionalism and do the best you can.
It is interesting that this one is the last on the list.
You should at least have some results after conforming to previous principles, right?
Get some figures ready for checking.
You may say that since the process was so mechanical then we could just make up stories and win. AWS guys were smart enough to figure that and came up with some countermeasures.
One of the countermeasures is cross-examinations. Since you will be interviewed by so many people, it is very possible that you will recite some experiences multiple times. When you do, then you are up to some cross-examinations.
Different interviewers will sit together to exchange opinions and share what they heard. If things contradicts strongly then there will be negative impressions.
Scenario, Roles, Numbers
Everything you said should be based on a case, a scenario, or better, a story. It should have a cause, some developments and a result. The cause will need to be directly traced back to some customer / client. The result will also need to be directly reflected as customer value.
- My customer had such a problem…
- Customer were angry about the outage…
- The bug made 56 users lose their data…
- …after that the App runs 200% faster and user rating in App store went up 15%
- …that was our first design project in this region
- …the customer was so delighted, and introduced us 4 new customers
You should be 100% clear about the part you play in this story, and articulate it in a concise manner. Better you be an important player.
- There were 4 members in the team, I was responsible for…
- I managed a 20-people elite team, my daily job was…
- I was the only one who could use this programming language…
- Before I was involved, the case had been hanging for months…
You should be very sensitive to numbers. AWS is all about numbers. The company run mostly by numbers and APIs. Try to quantify everything you can.
- How much revenue was at stake?
- How many users are to be affected?
- How many problems were solved?
- How long did it take?
- How many testimonial emails received?
- How many customers did you have?
You will find your interviewer busy typing instead of looking at you. Internally they use a STAR format. If your answers were in this format, you are doing them a good favor.
These are pretty self-explanatory.