Going to share my experience here, hopefully it's useful to others. I'll note that what worked for me may not work for others.

My background:
Education: BS Computer Science top 20 University
Experience: 3.5 years of experience (2 at a bank, 1.5 at a fintech startup)
Location: NYC

Leetcode: bought premium, 55 solved (18 easy, 28 medium, 9 hard)

I started studying for interviews in mid-February, did phone screens around mid-March and final rounds at the end of March/beginning of April.

My process mainly centered around recognizing patterns in the types of questions asked and then learning deeply the concepts surrounding those types of questions. This involved a lot of research into what questions had been reported on Leetcode discussion boards and in the company slug for question frequency. I don't believe that memorization is a valid strategy for solving these problems in an interview setting due to the higher pressure, need to communicate thought process and amount of variance in the ways questions can be asked. Many questions asked of me were variants of questions on Leetcode but not the same, I won't disclose specifics due to NDAs.

That being said, I found that the most common types of questions that these companies require knowing the following inside and out.

• Binary tree traversals (pre-fix, post-fix, level order, vertical order etc.)
• Sliding window problems
• BFS and DFS (adjacency map, 2-d matrix, binary tree, Trie etc.)
• Trie initialization and traversal
• Sorted data structures (heaps, balanced binary search tree, linked/array list with certain data properties)
• Recursive backtracking, sometimes with memoization

There are obviously other topics to cover (Linked lists, stacks, graph concepts etc.) but I think you need to know the above inside and out to have a good chance to land offers due to the frequency of related questions. Once I had a good graps of the concepts, I stopped solving many leetcode questions as the solutions/approach mostly became obvious after thinking for a minute or two.

My approach within coding interviews is as follows

• Clarify ambiguity
• Write out happy path test case and some that hit key edge cases
• clarify more ambiguity if test cases reveal more about the problem
• Outline core algorithm in pseudocode, stub helpers in pseudocode
• Write core algorithm with stubbed helpers, you may be able to talk complexity and walk through edge cases here
• Build helpers
• Add more test cases if necessary and verify algorithm/complexity

My main tip is don't be afraid to take a little time early to build test cases and outline your algorithm, this saves a lot of time compared to having to rewrite actual code.

From a system design perspective, *** the system design interview https://www.***/courses/***-the-system-design-interview and this guy https://www.youtube.com/channel/UCRPMAqdtSgd0Ipeef7iFsKw were helpful. I think a lot of distributed system stuff you're kind of already going to know from professional experience or not. You can close some gaps but try to steer conversations to areas where you are comfortable. For me, I focused the deeper dives on data modeling and task processing since I'm more knowledgeable about that than say, microservices and client to server web flow.

Again, I hope this helps people out there with there prep. Good luck to all!