Congratulations on securing an interview with Amazon Web Services! This document will help you prepare for your Software Development Engineer interview.
During your day with us, you will have 5/6x 1 hour interviews, your Recruitment Coordinator will confirm this. You will be asked one technical question in each interview slot (i.e. a problem solving question) along with two or three behavioural questions based on our Leadership Principles.
Our interviewers usually spend about 30 minutes on the technical question and 15 minutes on the leadership questions, ideally leaving some time for your questions at the end. Don’t be alarmed if there is a third person in the room. Your interviewer may bring a fellow Amazonian who is in the process of being trained to become an interviewer.
Our technical interview questions will cover three main areas:
1. CS Fundamentals, Algorithms & Data Structures, Object-Oriented Design
3. System Design
CS Fundamentals, Algorithms & Data Structures, Object-Oriented Design
Your interviewers might ask you to design an algorithm to solve a problem. It can start like this: “Given n sorted arrays as input, generate a single sorted array as output.”
Make sure you understand the problem. You are not going to lose points for requesting clarification or ratifying obvious assumptions. We want to see that you are meticulous, capable of diving into a problem and providing a reasonable solution. In your actual dayto-day work, you would never try to solve a problem without understanding it first. We don’t want you to do this in an interview either.
Ask your interviewer as many questions as you want to. They are there to help you.
Once you understand the problem, keep an eye on the time. Do your best to come up with a solution. It is okay to start with something trivial or even inefficient. Be clear if it is a trivial solution and if there is time, begin the process to solving it in a more efficient way. Your interviewer will appreciate your awareness of other approaches to solve the problem.
Talk it through. We want to hear your thought process, no matter where it leads. Vocalizing is a great practice, especially when there is a chance of running out of time. It can mean the difference between “We ran out of time and I’m not sure where the candidate was going with their solution,” and “Although we ran out of time, what we spoke about was promising. Given another 10 minutes I know the candidate would have reached an optimal solution.”
Break it down into smaller problems. Look at specific use cases, edge-, and corner cases. You could also start by looking at a simplified version of the problem and then work your way up to the full scope.
Prepare to answer questions on commonly used Algorithms such as sorting, binary searching & Data Structures, such as tries, HashMaps and linked lists.
Don't be afraid to change your approach. If you suddenly think of a better way or you feel like a particular approach isn't working, tell your interviewer. Try a different approach. Most of the time our problems have many solutions, much like our day-to-day work.
We need engineers who know how to write production-quality code. We are not expecting you to write code for a product or solution that we could ship tomorrow, but we will be looking for evidence that you have the ability to write clean, well-structured code that meets our standards.
It is also important to note that we are not only looking at the syntax of your code, we are observing your ability to problem-solve, your analytical skills, and your creativity.
Good design is paramount to extensible, bug-free code. It is possible to solve any given software problem in a limitless number of ways, but as software needs to be extensible and maintainable, good design is critical to success. Using object-oriented best practices is one way to build quality software. You should have working knowledge of common and useful design patterns as well as knowledge of how to write software in an object-oriented way. Appropriate use of inheritance, aggregation, interfaces and composition will be helpful. You should expect to justify your design decisions and explain the trade-offs to your interviewer.
Make sure you understand the problem or coding challenge. Don’t hesitate to ask questions if the requirements seem loosely defined or are (perhaps deliberately?) unclear. There is no penalty for asking for clarification. You wouldn’t want to miss a key requirement or proceed towards a solution on unfounded assumptions.
Pick a coding language. We do not have a preference for which language you use, as long as you have a firm grasp on the fundamentals (e.g. coding conventions, decomposition, object-oriented design). Just be aware that the work you do at Amazon may not be in that language. This is not an issue – we allow time for establishing knowledge in unfamiliar syntax when you join an Amazon team.
Be vocal. Explain your thought process to your interviewer as you code. This helps communicate your solution and gives your interviewer an opportunity to correct misconceptions and provide high-level guidance.
Be aware of edge cases. The goal is to strive for a solution that’s correct in observable aspects, but sometimes there is a flaw in the core logic of a solution. Most often, the only bugs we see are in how the code handles edge cases (this is true of real-world engineering as well). Make sure your solution works on all of the edge cases you can think of and be ready to talk through each one that is identified.
Discuss any shortfalls that your solution might have. Have you taken shortcuts or implemented anything that you would not do in a real world situation? Maybe there is a solution that you decided not to proceed with. Why? Share these thoughts with the interviewer.
Do not use pseudo code. If you feel rusty coding without an IDE or in a specific language, it’s a good idea to refresh your memory and get comfortable coding with pen and paper. For your interviews, you will be coding on a whiteboard or paper. The most important thing an SDE does at Amazon is write scalable, robust, and well-tested code. These are the main criteria by which your code will be evaluated, so make sure that no bad input can slip through. Missed commas or typos here and there aren’t a big deal, but the goal is to write code that’s as close to production ready as possible.
Our engineering environment is distributed. It is rare for a single SDE to be asked to implement a complete, large-scale system. Instead, we assign ownership of open-ended and ambiguous problems, and it’s the SDE and their team’s job to come up with the best solution to each. To be successful, you must be able to communicate with the people around you.
To assess your skills in this area, we’ll start by asking an open-ended question. You will need to guide the conversation to understand the problem. It means asking questions, sketching on the board, and bouncing ideas off your interviewer.
Do you know the constraints? What kind of inputs does your system need to handle? You have to get a sense for the scope of the problem before you start exploring possible solutions. And remember, there is rarely one correct answer.
Think about concurrency, networking, abstraction, real-world performance, latencies, scalability, estimation, availability, reliability, caching and cache invalidation.
The system design interview is challenging, but it’s also a place to be creative and have fun imagining systems unbuilt. If you listen to the problem carefully, make sure you understand the scope, and take a clear, straightforward approach to communicating your ideas you will be half way to succeeding.
Design Topics to Review
• Software systems need software components, data stores, business logic and APIs, component relationships, and data flows. Reviewing existing software system design diagrams (especially SOA or distributed software systems) can be helpful for preparation.
• Scaling is critical for system design at Amazon. It is important to consider scaling when designing your software system. Prior to your interview be sure to research scalability concepts and technology including caching, load balancing, nonrelational databases, micro-services, and sharding.
• Knowledge of distributed systems, SOA and n-tiered architecture is important in answering system design questions. If you don’t work with these concepts already, be sure to review them prior to your interview.
• Large system designs often need to trade off availability, consistency, and other performance characteristics. Be prepared to discuss these and any other trade-offs you make in your design.
Steps in the System Design Interview
This section has been written with web/service development in mind. If you are interviewing for a niche role or for a specific team, such as a native (embedded) SDE role or a mobile SDE role, this question will be tailored accordingly.
• Ask questions. While the interviewer won’t try to trick you, they might be deliberately vague. It’s important to know what sort of design the interviewer is looking for, so ask questions to clarify. When asking your questions, start with the customer in mind. Who is the customer and what problem are you solving for them?
• As you ask questions, begin writing a list of requirements on the board. This should be the first thing you add to the whiteboard.
• Once you have a good idea of the problems the system you are designing is to solve, begin drawing a diagram on the whiteboard to express your ideas.
• Be prepared to discuss trade-offs in your design. With any software system there are multiple ways to design it. What advantages would yours have? Disadvantages? What if you were to change a component or process? Be prepared to justify your decisions.
• Operational performance of your system is important. Be prepared to answer the following: how will you ensure this system is working at an optimal level of performance? If a problem occurs, what would be involved in troubleshooting and resolving it? What are the points of failure and how can they be made resilient?
Most of the software we write is backed by a data store. Many of the challenges we face arise when identifying how to retrieve or store data for future use at scale. We have made Amazon Web Services such as DynamoDB available for the developer community to leverage the benefits of non-relational databases. The more you know about how relational and non-relational databases work and any trade-offs that exist between them, the better prepared you will be. However, we don’t assume any particular level of expertise.
Systems at Amazon have to work under strict tolerances at high load. While we have some internal tools that help us with scaling, it’s important to have an understanding of basic distributed computing concepts. Having an understanding of topics such as serviceoriented architectures, map-reduce, distributed caching, load balancing, etc. could help you formulate answers to the more complicated architecture questions you might encounter.
You won’t need to know how to build your own operating system from scratch, but you should be familiar with OS topics that can affect code performance, such as: memory management, processes, threads, synchronization, paging, and multithreading.
While you won’t be asked specifically about these topics, reviewing them could help you in your interviews. Your interviewers won’t be evaluating your ability to memorize the details of each
topic. What they will be looking for is your ability to apply what you know to solve problems whilst meeting any constraints of scale, scope or load.
Our Leadership Principles aren’t just an inspirational wall hanging. These Principles work hard, just like we do. Amazonians use them every day, whether they’re discussing ideas for new projects, deciding on the best solution for a customer’s problem, or interviewing candidates. It’s just one of the things that makes Amazon peculiar.
Leadership questions are based on Amazons Leadership Principles and will usually be structured as behavioural questions: “Tell me about a time when…” OR “Give me an example of…”
For these questions, talk about a specific example of a situation that occurred in your previous experience and make sure to utilise the STAR framework when answering
(Situation, Task, Actions, Result). A full list of our principles can be found on amazon.jobs.
Your examples can be from commercial experience, your own ventures, education, hackathons, open source projects, and any other area relevant to software engineering or computer science.
Make sure that your examples are about you. While information about your team and projects is interesting, we are looking for data on your contributions, how you behaved in specific situations and what actions you took.
Oh and we love data (good or bad), so if you can provide data to back up your examples (e.g. indication of volumes, metrics), it will give you an edge in the interviews.
Our application and interview process differs from role to role, but whether you are having a phone interview or a video/in-person Interview you can expect us to cover 3 main topics:
In order to get further prepared you can:
- Explore Interviewing at Amazon.
- Brush up on Comp-sci fundamentals, Data Structures and Algorithms.
- Do as many coding exercises as possible on Project Euler, Hacker Rank, Leet Code, Code-fights, Interview-bit.
- Watch the preparation videos below:
Amazon Leadership Principles
This video provides valuable insight to help you be successful when interviewing for Amazon’s Leadership Principles.
Amazon Coding Sample
This video dives into a coding example and how candidates should approach, analyze and solve such problems when interviewing at Amazon.
Amazon System Design Preparation
This video tackles a system design example question and how candidates should approach, analyze and solve such technical questions.
• Interviewers may offer tips/hints. Listen for these and collaborate with your interviewers.
• We will never ask a trick question or mislead you in any way with intention.
• You will not be asked questions about being stuck in a blender or about how many windows there are in New York.
• You are encouraged to be vocal throughout the interviews.
• During the interview you will be coding on a whiteboard/paper.
• Dress as you wish, we don’t have a dress code at Amazon so you can dress casual.
• Interviewers will be taking notes on their laptops during the interviews. Try not to get distracted and don’t worry, they are listening.
Finally, we really appreciate you taking the time to speak with us and want you to enjoy the interview process as much as possible. If there is anything you are unsure about or anything we can do to make your visit more enjoyable, let your recruiter know.