How I Prepared Coding Interviews and Got Amazon Offer

This summer I’m going to Amazon as an SDE intern. Despite the huge layoff waves, I’m super lucky to land an offer at a FAANG company.

Here I’d like to share some tips I learned throughout my preparation for coding interviews in the last two years.

Recognize patterns

I’ve seen many people who have solved 500+ Leetcode problems, but still have no idea when asked about a new problem. Memorizing the problems and hoping to get asked the same questions in interviews is purely based on luck.

I think the meaning of practicing Leetcode is to recognize the patterns in those practice problems. If you see enough problems and recognized the patterns, you should be able to deduce what techniques you would use (often more than one) to solve a problem once it’s shown to you.

For example, when there are repetitive elements in an array, you think of using a hash map. When you need to compare elements in two arrays, you think of using two pointers.

Here is an example of how I summarize the patterns in greedy algorithm. I followed each sub-pattern with practiced problems so I can check out some examples during a review.

Therefore, to get a better sense of how each technique applies to a range of problems, I recommend going through Leetcode problems in the order of techniques / data structures. Go from easy, medium, to hard in each section.

Data structures:

1. Arrays & strings
2. Stacks & queues
3. Linked lists
4. Binary trees & Binary search trees
5. Heaps
6. Graphs
7. Tries

Techniques:

1. Hash map
2. Two pointers
3. Sliding window
4. Sorting methods
5. BFS & DFS
6. Backtracking
7. Greedy algorithm
8. Dynamic programming
9. Classical algorithms, e.g. Union find, Topological sort, A* algorithm

I recommend AlgoExpert (not an Ad) where they sort problems into these categories and have video tutorials to explain the solutions. Going through these helped me a lot in recognizing patterns in future practice problems.

AlgoExpert “group problems by categories”

Plan before code

One mistake I made is trying to solve a problem with no or a half-formed plan. Code without a plan is like going on a trip without knowing where to go.

When solving a problem, I would first write comments to break down steps to approach a problem. For example, for Leetcode 20. Valid Parenthesis:

def isValid(self, s: str) -> bool:
  # create an empty stack
  # iterate char in string:
    # if char is left sign, push to stack
    # if char is right sign:
      # edge case: if stack empty, return false
      # if top of stack is its corresponding left sign, pop from stack; else, return false
  # return true is stack is empty (all left signs have corresponding right signs)

Be aware of edge cases! When writing out the steps, look for possible edge cases that would break the code. They often are null value, empty array, negative integer or zero, etc. The edge case here is an empty stack, which will produce error when popping from the stack if not handled.

Run examples by hand. Take examples in the problem into your steps and see if they would work out. If not, the step-by-step process makes it clear when finding which steps went wrong.

Then I would “fill out” code below each comment. If the comments are from a good plan, writing code would be simple as translating text into code.

def isValid(self, s: str) -> bool:
  # create an empty stack
  stack = []
  lefts = {'(' : ')', '[' : ']', '{' : '}'}

  # iterate char in string:
  for char in s:

    # if char is left sign, push to stack
    if char in lefts:
      stack.append(char)

    # if char is right sign:
    else:
      # edge case: if stack empty, return false
      if stack == []:
          return False

      # if top of stack is its corresponding left sign, pop from stack; else, return false
      top = stack.pop()
      if top == lefts[char]:
          continue
      else:
          return False

  # return true is stack is empty (all left signs have corresponding right signs)
  return True if stack == [] else False

Check your code after finished. Make sure there is no syntax error that would break the code. If you are not sure, run through an example again.

Overall, having a good plan not only helps you organize your thoughts, but also shows your thought process in real interviews. Remember, the purpose of coding interviews is to examine how you would think and act when solving a coding problem, just like completing a task for the company. Your thought process often shows you as a better candidate than your code does.

If you’re stuck

Don’t panic when you are stuck. We all get stuck at some points when having problems we don’t fully understand.

If you are stuck in a practice problem, don’t be too hard on yourself. Allow yourself to check out solutions and video explanations after 5–10 minutes of stagnant progress. This would lead you to a clear approach to solving this problem and helps your learning better, compared to figuring out a rugged solution using 30+ minutes. Come back to this problem a few days later and use what you have learned.

If you are stuck in an interview, don’t hesitate to ask the interviewer to give you some hints. Showing your thoughts by asking questions is better than staying silent and having little progress. A good way is to think of your interviewer as a coworker, where you two are trying to solve a task for the company together. Your interviewer might be your coworker in the future, so showing your communication is important.

Do mock interviews

Lastly, I strongly recommend doing mock interviews. A month before my real interviews, I scheduled mock interviews on Pramp every week. Pramp connects you with another person and interviews each other with an assigned problem that fits your level.

How a mock interview on Pramp looks like

Doing mock interviews have many benefits:

1. Practice explaining your thoughts. While LeetCode helps you practice solving problems, mock interviews help you practice explaining your thoughts like in real interviews.
2. Learn from others. Seeing how others solve coding problems helps you learn from their strengths and mistakes. Take these opportunities to reflect on how you would improve in your interviews.
3. Receive feedbacks. Ask what others think about your performance in the mock interviews. Most real interviews don’t have feedback, so this is a great opportunity to directly know what you should improve.

Best luck with your interviews! Happy coding :)

Connect with me on LinkedIn

My technical blogs on Dev Community