Overall

• YOE: 4 years in non FANG IPO company in bay area.
• Interviewed with MSFT, AMZN, GOOG, FB and a startup.
• AMZN SDE2: rejected after virtual onsite.
• Startup: rejected after phone round.
• Specific details during interview, e.g, specific questions, are not disclosed. Some general examples/interview flows are mentioned. (The intent is to share personal experience of interviews and preparation. A virtual/read experience of going thru the 3-month interview stage. Below information is not about how to pass a specific interview in the front or what questions a specific company will ask.)
• Private data not related to experience/preparation will not be disclosed.
• Everyone has his/her own best way of learning. Interview result is a combination of talent, effort, luck, calmness and good sleep before interview day. I wish the best of luck to all of us.

Preparation

Coding

• MIT Open Course 6006 on youtube.
  Total 24 * 50 minutes video were learned in 8 weeks.
  Set up plan to go over two videos each week in beginning.
  Realized I had to go faster in final 2 weeks, and tried 1 video per weekday and 2-3 videos per weekend day.
  Highly recommended especially for DP thinking.
• Data structure and algorithm class in local college
• Leetcode
  Started 2 years ago with frequency of 1.5 per week. Redo and did rest beteen Jan and March (2.5 months)
  Leetcode: 300 Easy, 260 Medium, 25 Hard,
  Viewed and thought over another 25 hard before interview but did not implement them
  Leetcode Premium: Did not purchase.
  Towards the end, I could not come up with optimal solution on my own for roughly 5% of leetcode medium.
  Rough Speed (including both optimal and non-optimal):
  Easy 4 to 12 minutes, Medium 6 to 40 minutes, Hard 15 mins to 1.5 hrs
  Acceptance rate is 40%. Maybe higher towards the end.
  In mid of preparation stage, I try my best not to look at solution unless I think mine is optimal. (Could be non-optimal in some cases.)
  Optimal ideas could come when I was not coding and doing something else, e.g, working out in gym or dreaming during sleep.
  When I do leetcode codings, I also look at readness of codes. Coding style should be similar to industry codes, clear logic/no redundant lines/self explain.

Design
G***K on edu***io. (Not sure if I shall advertise this on leetcode, ask your friends for full name.)
I reviewed fundamental chapters and then all example chapters in two weeks. I already started some interviews and had cofidence in coding at this phase. I read 1-2 chapters over a weekday and 4-6 chapters over a weekend day.
Wrote a one-page summary of system design and did 2 examples before interview.
The design learning doc above is highly abstract. So if there are specific details I wanted to understand more, I searched them on youtube, e.g., caching, load-balacing, round-robin, md5 hash. I randomly pick a 10-mintue video with high views and ratings. These examples may not be asked but they ensure my distrubuted system knowledge are conncected with less holes.
There are tech challenge questions which you may have not learnt in distributed system examples. The material is a toolbox, and just think what tools you would pick to solve these challenges.
Also do understand the caveat and tradeoffs in your design.

I am not sure if in-depth knowledge of system design techniques is required. I just learned the fundamentals before interviews and tried my best to show my problem cracking skills/brainstorming speed/covering all aspects/fundamental distributed system understanding.
A generalized example: X company is going to launch a S service. You can identify servers, APIs, DB key-value, data sharding, think of some algorithms/techniques, optimize caching, load balancing, caveats of the algorithms. First go over a big picture of distributed systems flows. Then interviewer will focus on one part of the distributed system or give you specific questions. "Bad server", "latency is more important", "hot servers", "location based", etc., you can also lead the design and communicate these assumptions/concerns with interviewer. If interviewer thinks this is a valid and important concern, he/she will ask a follow up.

Behavior
Didn't realize the importance and didn't prepare for AMZN.
Did one-day mock interview with my wife and I could feel the big difference.
AMZN asked a lot of behavior questions so it's important to be prepaired.

My wife was in non-tech position, so she's pretty much my mentor and teacher on behavior questions.
Special thanks to her here. :)
Some key take aways which I think could be helpful:

1. Example questions can be found every where. After preparing 10+ questions, I got the idea that some questions are similar. And if there is a question type I have never met, preparation still gives me insight on how to approach it.
2. I repeated my answer to a behavior question 10+ times when I was doing mock interview with my wife. I moved on to next question after I was satisfied with my current answer. She took notes for me to review later.
3. Interviewers also takes notes. So you want to highlight some key words of your core strength from both tech and non-tech side.
4. Team player: I have experience in knowledge sharing/collaboration/how to deal with disagreements/how to align priorities.
5. Individual contributor: how I learn things fast/ how I crack problems/how I multi-task
6. Being considerate and think over all aspects of things.
7. I guess 4-6 are my core strenghts, so I prepared examples to "share" with my interviewer when a related question is asked. I am sure every one has different type of core strengths. Just think as you were the employer, what key shining points this candidate has which could benefit your company as well as differentiate him/her from others.
8. Prepare 15+ behavior questions, and try to show all your main shining points in the answers.
9. Answers should be in a logical way. It's still a conversation and you should not redirect answer too far from the question.
10. What "negative points" did you experience in past and how did you overcome/learn thru it? Briefly explain a "minor negative point" and focus more on how you overcome it and what are the positive results after that.
11. Hypothetical behavior question can also be asked. If you are in XXX situation, what are your planned actions. AMZN focused on their leadership principle related questions.
12. There are no pefect answers to behavior questions. These are open questions and answers shall serve the purpose to show why you are a good candidate.
13. Some thing might look easy for you and you didn't realize it's your strength. Preparing behavior questions is also an opportunity for you to review yourself and find out your own core strengths.
14. STAR method: Situation - Task - Action - Results

Interviews (Personal Experience only)

Frequent algorithm: topological sort, backtracking
Data structure: trie, priority queue
Google: 6 rounds of onsite interviews. (not normal)
Interviewers were encouraging and good listeners and gave me time to figure out issues myself.
Or they were trying to see the 100% of me. (Both positive and negative sides.)
1 round behavior + 1 round of non-distributed-system design question.
FB: Phone + virtual.
Phone:
Finished two questions which look very similar to leetcode medium questions in 30 minutes.
I told interviewer I had already done similar question and knew the optimal solution for worst case.
So I briefly explained optimal solution + brutal force solution.
Came up with a 3rd solution of best average performance and wrote code on it.
Virtual:
2 rounds of coding + 1 round behavior + 1 round system design
AMZN: OA+Phone+virtual.
Phone: two medium level. 1 leetcode question + 1 question I did with priority queue
Virtual:
3 rounds of coding + 1 round system design with a manager.
Each round starts with 15-20 mintues of behavior questions.
Interviewers tried to be nice but they had to ask those difficult behavior questions which I did not prepare.
MSFT (Flied to Seattle):
OA+onsite
Onsite:
Trip and hotel to seattle were accomodated by company.
4 rounds of 45 minutes. 15 minutes break in between.
Each round starts with 10-15 minutes of behavior questions.

Interview Tips

Communication: Companies are hiring people who can collaborate. Explaining your ideas is very important. It also prevents you from the wrong direction.
Clarification: I usually make up some test cases to confirm with interviewer if my understanding is correct.
Speed: If you believe your optimal solution, don't waste time on explaining non-optimal ones. I also do express my optimal idea to interviewer to see their feedbacks before jumping on coding.
Picture thinking: I love picture thinking and do draw diagrams. Drawings are similar to what professors are teaching on the blackboard. e.g., if I am going over test cases on recursion, I would draw a stack diagram.
My interview steps:

1. "Can you clarify this "XXX" part of the question?"
2. "Just want to confirm if my understanding is correct, if with this input1, the output should be like output1? (Maybe add a second example.)"
3. "I have an idea on how to approach this problem. (I think it's optimal / I think it may not be optimal but I will optimize it later.)"
4. Briefly explain the idea, maybe with some simple drawings. (You may realize a bug during explaination, then correct it while explaining it. Don't worry about pointing out your own mistake as mistake is acceptable in draft thinking.) Give 2 line big-o analysis, time and space.
5. Collect feedback and interviewers may point out your misunderstanding or defects in your idea. Don't be defensive! Appreciate those feedbacks. Making mistakes is not the end of the day, but being defensive means you are not a team player.
6. If you really think yours is correct and interviewer misunderstood it, then explain it clearly. Interviewers are usually smart and will absolutely understand it with a 2nd chance.
7. Write code super fast and address corner/border cases in the end or along the way. If a corner case is covered by general methods, it's not that "corner". I prefer to mention it's already covered and will not add redundant if conditions.
8. "I think my code should be working. Can I go over some test cases and see if there will be bugs or corner/border cases I have to fix?"
9. Make drawings and go over some different type of test cases. (Base->Complex or Different coverage area) Drawings can be arrays and indexes, arrows for pointers, current variable status, diagrams, data structures and etc.. Fix bugs in code if any. Drawing is a little hard in virtual onsite. I was able to type current variable status/arrays and modify them. But if it's time consuming, assume interviewer knows most part of your solution and don't go too deep in details.
10. Think if there are uncovered test cases. You can confirm if it's a good/acceptable solution by observing some facial expression from interviewer or if they give you a confident acknowledgement. e.g., "I think that will work". Once a confirmation is received, then don't waste time on other test cases. Save some time for follow up/2nd question/friendly chat.
11. Interviewers take notes about you and your thinking. They also copy your entire code for further review. If time allows, make it bug free.

My Beliefs

As one recruiter said, confidence is very important during interview.
If you are not confident, you could end up debugging same thing repeatedly.

Life learning is a long process and not a short term goal.
Alway keep learning no matter looking for a new opportunity or not.

Set up plans for short term, when looking for a boost.

Resolve bottlenecks if any before making your best skill more perfect.