Here are the 4 technical competencies they will be evaluating you on:

Problem Solving:

- Voice your thought process end-to-end.

- We may present a vague problem but we are not going to ask you an unsolvable one.

- If you find yourself at a point where you’re truly stuck, tell your interviewer.

- Talk through initial thoughts, gather requirements, determine and voice the most important piece of the problem, translate it to clean written code, find edge cases, etc.

- Sometimes we ask questions that have multiple solutions. we want to observe how do you deal with multiple solutions and compare them


Data Structures:

You should always know the strengths and weaknesses of any data structure that you choose, even if you don’t have to implement it
An important part of data structures is not necessarily, “could you implement it?”. It’s more important that you understand why and how you’d use a given data structure in a particular situation
Sometimes problems can’t be solved by a single data structure. How might you solve a problem with multiple data structures?
We expect you to consider runtimes for common operations and understand how they consume memory.
We also expect you to know the Data Structures you would encounter in core libraries. i.e. Trees, Hash Maps, Lists, Arrays, Queues, etc.


Algorithms:

We don’t expect you to remember and repeat existing algorithms (like search algorithms), but we want to see how you work with algorithms and create algorithms
**We expect you to handle edge cases that may arise with the algorithm you’re working with or created
You should also have a good understanding of most common algorithms, runtimes, theoretical limitations, and basic implementation strategies for different classes of algorithms.
Sorting and traversal algorithms, breadth first search (BFS) and depth first search (DFS) are big ones, tree traversal, graph traversal


Logical & Maintainable Code:

Your code should be understandable without comments or complex explanations
We value “logical & maintainable” code because it allows engineers to work with your code, and improves the stability and longevity of code. If you join Amazon, you own your own code. The engineer/team that wrote it maintains it. You may also write code for libraries which other teams and engineers at Amazon may use. Other reasons “logical & maintainable” code is a biggie for us
The level of perfection we expect in production-ready code may not be attainable in the time limit of an interview, and that’s OK. Try your best.
We prefer you to finish coding your solution with imperfect code than not finishing the problem, but writing perfect code.
When you’re finished coding, ask yourself… can you read through your own code and explain what it’s doing.
Code doesn’t be code doesn’t have to be 100% optimized but should convey the intent and the logic correctly.


System Design:

Won’t have to design an entire service – just a small part
Use diagrams on whiteboard – flow and be clean
Start with the customer and work backward. Understand the problem, what data will you need to solve it, etc?
You’ll probably have to ask a lot of clarifying questions.
No design is optimal, but we expect you to understand the strengths and limitations of your design
Expect follow-up questions around scaling, operational excellence, edge cases, failures, etc. Be prepared to speak to things like this
First 5/10 minutes gathering requirements and details - make it interactive
Looking to exhibit solid OO design patterns – Base level
Full Scalable system –High level