Amazon Interview Tips and Hints

Download as pdf or txt
Download as pdf or txt
You are on page 1of 2

Thank you for taking the time to speak with us.

The below tips are intended to enhance your candidate


experience.

Other Helpful Tips and Hints from our Engineers

Leadership Principles. Amazon assesses all candidates on our Leadership Principles. Be ready to show
how your experience and values overlap with these. While you do not have to memorize the leadership
principles, please study them and be prepared to explain how you have embodied these principles in
your own experiences. You will want to have 2-3 detailed examples for each principle. Try to avoid using
the same examples throughout your interviews; it is important that we see the breadth of your work
and results.

Treat the interview like your first day on the job. Imagine you were already hired and this was your
first assignment. Ask lots of questions and work to fully understand the problem statement. Don’t just
jump in and start coding. Ask questions. Write any assumptions down. Be clear - you should be eager to
jump up and use the whiteboard (for in-person) or type on Collabedit (for phone screens). Clearly state
any assumptions and ask clarifying questions. The interviewers will intentionally make vague/ambiguous
statements, and expect you to ask questions to get clarity.

Always think about scalability. Amazon deals with huge data sets – assume files/databases that are
10’s of terabytes at any time. Think about efficiency when working with such huge datasets and
incorporate it into your designs.

Start with the customer. Always start with the customer and work your way back. Never sacrifice the
customer experience because it’s easier to code something a certain way.

Be confident. Don’t be unsure. Ask questions if you are unsure, so you can get the answer and
confidently come up with a solution. It doesn’t have to be a perfect solution, or even especially elegant.
The interviewer will work with you to iterate and improve it if necessary. If you identify areas for
improvement in your code as you’re writing it, say them out loud. State that you have a more
efficient/faster/more secure way to accomplish this and ask if the interviewer wants you to take time to
write it out. Leave nothing unsaid. Be verbose but don’t use it as a stalling tactic – the
questions/clarifications need to legitimately add value to the conversation.
Use the STAR method when giving examples from your past. Situation, Task, Action, Results.
Come prepared with some examples stories. Don’t use the same examples with different people. Once
you use an example with one interviewer, don’t use it again (for in-person interviews).

Approach to solving problems:


1. Who’s the customer? (For on-site interviews. Phone screen problems are more CS fundamental
and don’t necessarily have customers)
2. What’s the problem to solve? (Restate for clarity)
3. What are the assumptions? (Clearly state)
4. What is your approach? (Be confident and state when you identify an area for improvement in
your code. Finding and fixing a bug in code you wrote earlier is not a bad thing. Take ownership,
call out the issue, and state why/how you are fixing it.)

**A good approach will identify as many relevant use cases as possible. We are just as
interested in hearing a coherent thought process as we are in seeing a workable solution, so talk
through your approach to the problem with the interviewer. Draw out a small sample set of
data to serve as a guide. Enumerate the many aspects of the solution (actors, use cases,
requirements) before defining an architecture. When you arrive at a shortlist of possible
solutions, verbally weigh the benefits and risks of each solution. Always solve the problem
algorithmically first and be sure to consider edge cases, corner cases and boundaries.**

Work through sample problems. In the week leading up to the interview, work through sample
problems from CodeChef.com, GeekForGeek.com, and Glassdoor.com. Pretend you’re in the interview.
Ask questions. State assumptions. Be confident.

You might also like