Amazon interview tips

Prepare stories matching Amazon leadership principles. Leetcode medium-ish questions are asked and system design is not that hard.

f

As someone else said, prepare stories that match LPs. Also be prepared to give details about these stories. Your examples must show adequate scope for the level you are targeting. Modify or simplify stories if you think the interviewer may not understand your domain/area of work. Most people seem fine at technical questions but get rejected due to stories not being good enough.

Each round is 15-20 minutes about leadership principles and the rest for either coding or design. For coding, it depends on the position but practicing leetcode amazon tagged questions should be enough. Prepare a lot of stories for LP. Good luck.

A lot of candidates are rejected for culture fit issues, especially industry hires, so do not neglect the behavioral part of the interview. Prepare a good story to tell for every leadership principle. Tell your story in the STAR format - Situation/Task + Action + Result (search STAR format for more details). Try to come up with your own fake questions for each leadership principle, so that when you're asked about behavioral questions, you know which leadership principle they want to hear about. For system design, be familiar with object oriented design patterns, and microservice architecture. If you're familiar with concepts from Cracking the System Design Interview, you should be fine. Make sure to clarify requirements and think out loud. Think about who your users/customers will be, and also think about failure cases, and how you will test and audit/monitor your system. For coding, leetcode medium is generally good enough. Interviewers do come up with their own questions for the tech part though - there's no standard question set - so you could get anything. Some may do their own spin on a leetcode problem, or (more rarely) have a completely original problem. So don't assume you know the problem because you saw something similar before. Listen to the whole description and take notes. The rest of my advice is applicable to most places that have reasonable interview expectations, not just Amazon: It's generally not required to have the most optimal solution if it requires a lot of tricks. While at least partial optimization is preferred, if you do not know how to make something better than brute force, a complete and correct brute force solution plus discussion on ways to optimize it will often be perceived as better than a non-functional attempt at optimization that doesn't give the interviewer confidence you'd at least eventually get there. Ask questions to clarify requirements and edge cases for the tech part, and come up with test cases. Think out loud while coding. Be able to verbally step through your code when you're done. Know how to analyze the complexity of your code. And be prepared to answer follow up questions (eg. how might you approach making an even faster/lower memory solution? What if you had to generalize it to take in different data types? What if you know ahead of time that your inputs will be a certain size/length/etc. then is your solution still optimal? Etc.)