Interviewing for a Software Development Engineer role at Amazon usually takes four to five weeks overall. First you complete an online assessment followed by a virtual interview. You then interview with Amazon Software Development Engineers and Software Development Managers.
Read on for interview tips and to learn more about the steps in the interview process.
If you're interested in additional prep details, visit the Interactive Amazon SDE Prep Guide.
The questionnaire is designed to collect your preferences for job location, item or product domain, tech stack, work environment and career goals. While we cannot guarantee all your requirements will be met, we will match you to the teams that most closely match your interests. You will have the chance to speak with those teams before making a decision to join Amazon.
You will have 90 minutes to complete two technical questions followed by 20 minutes of Systems Design scenarios, and an 8 minute multiple choice Work Style Survey related to our Leadership Principles.
Languages you can use: C#, C, C++, Java, Python, Golang, Ruby, JavaScript including 9 additional languages.
For the second part of the process, we want to see your system design skillset applied to a few fictional situations with simulated peers, managers, and stakeholders. When responding to these scenarios, put your system design hat on, and employ system design concepts like designing for maintainability, determining tradeoffs, and dealing with ambiguity. You will not be requested to complete a whiteboarding or a diagram exercise. Simply rate what you believe are the most effective or ineffective actions to take given the scenario. The assessment should take approximately 20 minutes.
The Code Itself
We are interested in your demonstration of problem solving, writing correct code, applying patterns/data structures, and optimizing for algorithmic performance on the tests. Don’t take preparing for this lightly, it will require you to study.
2) AFTER you have solved a solution that passes the test/edge cases, THEN go back and optimize the solution.
Compiler?
If you feel like your solution is mostly correct but you are facing some final compile issues, do not worry. Attempt to solve both of the challenges to the best of your ability.
Copy, Paste...
Dishonest behavior will be caught. The assessment records everything once you begin. If you copy and paste code from outside it will be recorded.
Algorithms: Basic Searching, Basic Sorting, Tree Traversal, Graph Traversal
Data Structures: Heaps, linked lists, arrays, trees (esp binary search trees), hash tables, stacks, and recursion
Fundamentals: Go back and re-educate yourself on all data structures and data structure algorithms. Understand all time and space complexity. Make sure you even get into more exotic things like hashmaps, b+trees (and variants), caches (and associated algorithms). Visit www.codechef.com for practice.
Understand high scale architecture. Go look at how other big sites are structured: http://highscalability.com/blog/category/example
Project Euler - http://projecteuler.net/ If you’ve been out of practice, complete up to problem 60 or so. You should be prompted to build useful libraries, which will help give practical experience for interview like problems. Don’t cheat or take shortcuts.
Google Coding Contest has additional practice questions: https://codingcompetitions.withgoogle.com/
Pramp - Pramp is a site where you can do mock phone/video interviews with another person. You take turns interviewing with another professional. You can split up the time however you deem fit.
You will have three separate interviews evaluating three areas of coding; logical and maintainable, problem solving, and data structures and algorithms.
Your interviewer will pose an intentionally vague question to evaluate your ability/approach to solve problems. Engage with your interviewer and ask clarifying questions.
Consider runtimes for common operations and understand how they use memory. Understand data structures you encounter in core libraries. i.e. trees, hash maps, lists, arrays, queues, etc.
Understand common algorithms. i.e. traversals, divide and conquer, when to use breadth first vs. depth first recursion. Discuss runtimes, theoretical limitations, and basic implementation strategies for different cases of algorithms.
After you’ve gathered qualifying requirements - translate into clean written code, checking edge cases. While you’re coding, ask yourself “If someone looked at this code in the future, would they be able to understand it without explanation, comments, or documentation?”
We expect you to produce enough code for us to evaluate how your solution addresses the problem.
Ensure your code is scalable, robust, and well-tested.
Be familiar with prominent languages, including the syntax of the language.
Be prepared to discuss technologies listed on your resume. i.e. if you list Java or Python, expect technical questions about your experiences with these technologies.
Before Coding:
Ask clarifying questions
Voice your assumptions
Ask for examples and use them to validate your ideas
During Coding:
Explain your decision making
Describe your code
Write syntactically correct code, no pseudo code
After Coding:
Test your code
Topics to review:
Visit codechef.com or similar websites to brush up on problem solving and core CS fundamentals.
The book "Cracking the Coding Interview" has a lot of valuable content.
Take a few minutes to watch the following videos covering what to expect in the coding assessment.
Check out our interviewing tips for SDE topics - you will be interviewed and measured in many of these functional skills during your interview process. The level of measurement is defined by scope, scale and impact. Your interviewers won't be evaluating your ability to memorize all of the details of each topic. They will be evaluating your ability to apply what you know to solve problems efficiently and effectively. Be sure to practice coding outside of an IDE and review Computer Science fundamentals.
We do not require that you know any specific programming language before interviewing for a technical position with Amazon, but familiarity with a prominent language is generally a prerequisite for success. Not only should you be familiar with the syntax of a language like Java, Python, C#, C/C++, or Ruby, you should be familiar with some of the languages' nuances, such as how memory management works, or the most commonly used collections or libraries, etc.
Good design is paramount to extensible, bug free, long-lived code. It's possible to solve any given software problem in an almost limitless number of ways, but when software needs to be extensible and maintainable, good software design is critical to success. Using Object-oriented design best practices is one way to build lasting software. You should have a working knowledge of a few common and useful design patterns as well as know how to write software in an object-oriented way, with appropriate use of inheritance and aggregation. You probably won't be asked to describe the details of how specific design patterns work, but expect to have to defend your design choices.
Systems at Amazon have to work under very strict tolerances at a high load. While we have some internal tools that help us with scaling, it's important to have an understanding of a few basic distributed computing concepts. Having an understanding of topics such as service oriented architectures, map-reduce, distributed caching, load balancing, etc. could help you formulate answer to some of the more complicated distributed architecture questions you might encounter.
Most of the work we do involves storing and providing access to data in efficient ways. This necessitates a very strong background in data structures. You'll be expected to understand the inner workings of common data structures and be able to compare their usage in various applications. You will be expected to know the runtimes for common operations as well as how they use memory. Wikipedia is a great resource for brushing up on data structures.
Your interview with Amazon will not be focused on rote memorization of algorithms; however, having a good understanding of the most common algorithms will likely make solving some of the questions we ask a lot easier. Consider reviewing traversals, divide and conquer, and any other common algorithms you feel might be worth brushing up on.
For example, it might be good to know how and when to use a breadth-first search versus a depth-first search, and what the tradeoffs are. Knowing the runtimes, theoretical limitations, and basic implementation strategies of different classes of algorithms is more important than memorizing the specific details of any given algorithm.
Most of the software that we write is backed by a data store, somewhere. Many of the challenges we face arise when figuring out how to most efficiently retrieve or store data for future use. Amazon has been at the forefront of the non-relational DB movement. We have made Amazon Web Services such as DynamoDB available for the developer community that let them easily leverage the benefits of non-relational databases. The more you know about how relational and non-relational databases work and what tradeoffs exist between them, the better prepared you will be. However, we don't assume any particular level of expertise.
You're interviewing at Amazon. We do a lot of business online, and we expect our engineers to be familiar with at least the basics of how the internet works. You might want to brush up on how browsers work at a high level, from DNS lookups and TCP/IP, to socket connections. We aren't looking for network engineer qualifications, but a solid understanding of the fundamentals of how the web works is a requirement.
Expect to be asked to write syntactically correct code - no pseudo code. If you feel a bit rusty coding without an IDE or coding in a specific language, it's probably a good idea to dust off the cobwebs and get comfortable coding with a pen and paper. The most important thing a Software Development Engineer 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 you check for edge cases and validate that no bad input can slip through. A few missed commas or typos here and there aren't that big of a deal, but the goal is to write code that's as close to production ready as possible. This is your chance to show off your coding ability.
You will have one interview focused on system design. Be prepared to white board. Practice drawing your system design by hand.
Engage with your interviewer and ask clarifying questions. While the interviewer won’t try to trick you, they might be intentionally vague to push your innovation. It’s important to know what sort of design the interviewer is looking for, so ask questions.
Start with the customer in mind. Who is the customer and what problem are you solving for them?
As you ask your questions, begin writing a list of requirements on the board. This should typically be the first thing you add to the white board. Think out loud as you write out your design and show us your ability to solve problems.
Begin drawing a diagram once you've asked enough clarifying questions and gathered the necessary requirements to begin white boarding your system design solution. Start with shapes to represent different software components and data sources, and then arrows connecting them to show web services, APIs and interactions between components.
Scaling is a critical component of software design at Amazon. It’s important to consider scaling when diagramming and designing your software system. Be sure and research scalability concepts and technology prior to your interview such as caching, load balancing, non-relational databases, micro services and sharding.
Resources:
Know how your solution solves the problem. If you suggest technology to help solve, understand how that technology works.
Operational performance of your design is important.
Ask sufficient questions to clarify the requirements (dealing with ambiguity).
How will you ensure this system is working at an acceptable level of performance?
If a problem occurs, what will be involved to trouble shoot and resolve quickly?
What are the possible points of failure and how can they be made more robust against failure?
Be prepared to discuss trade-offs in your design. With any software system there are multiple ways to design it.
What advantages & disadvantages would yours have?
What if you were to change a component or process?
Deliver a design in production with considerations of deployment, scaling, failures, availability, and performance.
Be prepared to discuss latency and concurrency.
Topics to Review:
Often times, software systems need software components, something to store data, something to make decisions (such as business logic) and APIs or processes. Reviewing software systems design diagrams (especially SOA or distributed software systems) can be helpful for preparation
Knowledge of distributed systems, SOA, and n-tiered software architecture is very important in answering systems design questions. If you don’t work with these concepts regularly, be sure to review them.
Take a few minutes to watch the following video covering Design,
Each interview will include 2-3 behavioral based questions. These questions ask about past situations or challenges you’ve faced and how you’ve handled them, using Leadership Principles to guide the discussion.
Keep in mind, Amazon is a data-driven company. When answering your questions, your focus should be on the question asked. Ensure your answer is well-structured and provide examples using metrics or data when applicable. Reference recent situations (within the last two years) whenever possible.
During your interview, you can expect to have eight different Leadership Principle related behavioral questions.
When answering these questions, utilize the STAR method:
Situation: Open with a brief description of the situation and the specific context of the story (who, what, where, when, how).
Task: Explain the task you had to complete highlighting any specific challenges or constraints (deadlines, costs, other issues).
Action: Describe the specific actions you took to complete the task. These should highlight desirable traits without needing to state them (initiative, intelligence, dedication, leadership, understanding, etc.)
Result: Close with the result of your efforts. When possible, include data to quantify the result.
Here are examples for 10 out of 14 Leadership Principles
At Amazon, we use our Leadership Principles every day whether we're discussing ideas for new projects or deciding on the best approach to solving a problem. We rely on them to help us make hiring decisions. The best way to prepare for your interview is to practice using the STAR method to outline how you’ve applied using the below principles in your professional experience. Follow the link above for a detailed explanation of each Leadership Principle.
They will generally sound like “tell me about a time when…” or “Give me an example…” and will usually incorporate the Amazon Leadership Principles. Remember, interviews are generally historical and focus on the “what” and the “how” of your experience, as well as the “why” of your decision process.
It's also important to get to know our products and familiarize yourself with exploring about Amazon. We are all very passionate about our products and the way in which we're building it, so we want to hire people who are also pioneers and love it!
Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers. Always be sure to mention the customers in your example(s).
Example Question:
Tell me about a time you worked backwards from a customer problem — how did you solve it?
Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best. Leaders garner respect and drive consensus and influence others by being right a lot; clearly, directly, promptly and appropriately communicate; and be open and listen to new ideas and ways of getting things done.
Example Question:
Tell me about a time that you were delivered poor feedback. Tell me about a time that you did not work well with another individual.
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
Challenge decisions when he or she disagrees; has conviction and is tenacious, not compromising for the sake of social cohesion; once a decision is determined, they commit wholly; challenges "the way it has always been done"; demonstrates the courage to do what is right for the business and/or customer.
Example Question:
Describe a time when you disagreed with your manager.
Leaders have relentlessly high standards - many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.
Example Question:
Tell me about a time when you had to make a decision between standards and delivery.
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job".
Able to grasp what is business critical and best for the business and our customers. Candidates will demonstrate strong commitment to long-term success; work to obtain optimal return on investment from available resources; accept responsibility for actions and outcomes; take initiative and be persistent.
Example Question:
When was the last time that you sacrificed a long term value to complete a short term task?
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here". As we do new things, we accept that we may be misunderstood for long periods of time. Candidates are resourceful and discover ways to invent while also finding the simplest solution. Designs and solutions should be both novel and simple. Avoid over- complicating solutions and demonstrate your ability to think outside the box to address problems creatively.
Example Question:
Give a specific example where you drove adoption for your vision and explain how you knew it had been adopted by others.
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
Self-motivated to learn themselves rather than needing to be taught; open to new ideas and ways of getting things done; able to seek and take feedback; able to take learnings from mistakes to better oneself; curious and has a passion to learn; passionate about keeping updated with new technologies; able to grasp new concepts quickly; able to come up to speed in a new area quickly and comprehensively.
Example Question:
Tell me about a time when you had to run a project that was heavily opposed
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
Quickly identifies if more information is needed before taking action; analyzes facts quickly; is able to evaluate data and information effectively; and uses own initiative to drive forward.
Example Question:
Tell me about a time you had to make a decision with incomplete information. How did you make it and what was the outcome?
Technology – We are a technology company. Be as technical as possible in your answers.
Follow-up questions – Think about why the interviewer has asked the question, it might give insight to what they are looking for.
Use multiple examples – We recommend not using the same story or example more than once.
"I" before "we" - This interview is an opportunity for Amazon to learn about what you have owned and accomplished. Use words like “I owned” or “I did” and avoid “we did” or “my manager…”.
Dive into specifics and details rather than discussing 30 thousand foot conversations. If you bring up something, for example “IoT”, you should be ready to explain it; in depth.
Be detailed and specific, avoid rambling or including too much information. Don't generalize about several events; give a detailed account of one event when providing examples. Leaders dive into the details and provide data to support reasoning.
Dealing with ambiguity - Demonstrate that you can handle intentionally vague requirements; change strategies quickly when approach doesn’t work; work through open ended questions; is adaptable & quick learning.
Confidential information – Never share confidential information about your current or past company. Besides putting us in an uncomfortable situation, how do we know you won’t share our information (Earns Trust).
Did you mention the customer? Amazon is customer obsessed and it is highly important you include the customer, whether internal or external in your situation. Be Able to put the customer's viewpoint by starting with the customer working backwards.
Eliminate any examples that do not paint you in a positive light. However, keep in mind that some examples that have a negative result (such as “lost the game”) can highlight your strengths in the face of adversity. Strong ability to deal with ambiguity.
Notes – Candidates are allowed to have notes during the interview, but don’t become dependent on them. Make sure to call it out to the interviewer as well.
