Recruiter reached out and asked if I wanted to interview. Applied a year ago and forgot about it sot it was a real surprise when I got the email.
He went over my resume a little bit and asked about my interests. No technical questions. He had me schedule the phone interview and I asked for a
month to prepare. After the phone interview, I asked for 3 more weeks to prep for the onsite.

LeetCode:
Total: 266
Easy: 103
Medium: 141
Hard: 22

Google Interview prep in explore tab:
81% completed

Phone:

1. Prefix Tree / Trie / N-ary tree - Easy or Light Medium
   a. Create a tree from a string
   b. Print the tree
   c. Similar to printing out a filesystem folder structure after getting a bunch of file paths

   Experience:
   He was kind of hard to understand as we were on the phone, and he had an accent, but I understood the question.
   It was a pretty simple question but I took about 5 minutes to understand what it was asking and come up with the solution.
   Recruiter said it was really positive and was going to up the next interviews to be for an L4 position.
   Didn't have to do a 2nd call.

Virtual Onsite:

1. N-Ary Tree - Medium
   a. Create the tree from an array
   b. Delete a node
   c. Delete a subtree

   Experience:
   Interviewer was a young dude who was pretty friendly, and not too involved once I was coding. I was really nervous for this one.
   I felt that it was a straight-forward problem, but I did stumble in my explanation on my approach quite a bit. Once I started coding, my
   explanations got better. I had an idea to use a hash set for a smaller part of my solution to make it more efficient, but he said not to
   worry about it and the O(n) implementation I had was fine. I'd rate this one a 3.5/5 - 4/5

2. Very similar to this https://leetcode.com/problems/minimum-area-rectangle/ - Medium
   a. Asked me to make a couple test cases and step through them. I found a bug and fixed it.
   b. Also asked me to change some variable names and do other things to help readability.
   c. Spoke a lot about optimizations. Really wanted a thorough explanation of my thought process and my thoughts on time complexity/ways to improve it.
   d. He didn't ask me to code the more optimized solution we came up with. He just wanted a quick explanation of what I'd do. Although, I could have coded it if he asked.

   Experience:
   Interviewer was another young guy who was more friendly than the last. Much more involved while I was coding. I may have confused him on my approach,
   or he just wanted me to thoroughly explain what I was doing. We bounced ideas off of each other and had a good discussion.
   He said I nailed it. I think I nailed it. 5/5

3. String parse and replace - Hard
   a. This was definitely a hard one
   b. Involved a hash map and iterating over the string
   c. A bunch of caveats as I asked quesions

   Experience:
   Interviewer got right to the question and I figured I'd get a hard one after the last interviews. It was over the phone. While I did not have enough time to finish coding my solution,
   I communicated some optimizations I would make to speed it up, and what I'd do to code the rest. I didn't get around to solving a smaller issue that
   could come up, but I did state my approach. I don't feel I did amazing here but I don't think I bombed it. I was never completely stuck, nor did I think he gave any hints on how to solve it.
   He did point out a minor bug where I didn't initialize a variable. I'd rate it anywhere from 3/5 - 4/5 if we are just going by my solution.
   Might be a 4 if they are generous because of my approach/communication/explanation.

4. Behavioral
   Not difficult at all. Standard Behavioral interview.

   Experience:
   Interviewer was older than the last ones but was just as friendly. I think I did well. He liked my answers and we had a good back and forth.
   As long as you aren't a psycho, egotistical, or extremely nervous, it is pretty easy. Felt like I spoke a lot but I'm self conscious about that so 4/5 - 5/5

5. N-Ary Tree
   a. Least common ancestor - Medium
   b. Find nodes that are N deep from given node - Easy

   Experience:
   We started somewhat right away. I don't know quite how to feel about this one. I knew how to solve it and didn't really stumble through it.
   It was a lot of coding and I ran short on time due to setting up the classes and solving the first problem. I did code up the second one as fast as possible.
   I believe my thought process was shown. I stated what I'd do to make it faster given more time. It was a long problem, but not a particularly hard one.
   I was pretty tired for this one and I made some simple errors while coding this up. The interviewer gave some hints to errors I made in my code and I recognized and fixed them. They
   were relatively minor. He liked the clarifying questions I asked at the beginning. Due to the length of this problem, I'd rate it as a hard. Though, if you know
   some basic tree stuff, this wasn't nearly as difficult as the previous coding question. Unless I misunderstood the question or took too long to get to the harder part of course :)
   I'd give it a 3/5 - 4/5

Summary:
Pretty much every question was straight forward, and the core of the problems were not vague. Some deeper clarifying questions were needed for last 2 technical interviews.
None of the problems really stumped me in how to solve them. If there were any negatives in my performance, it came from the communication and how accurately I implemented
my solutions.

My words per minute while typing the last one was off the charts. I was zooming to finish it while trying to explain it. I think I was quite lucky with these interviews.
I thank whatever god above that made it so I wasn't asked any complicated dynamic programming or greedy questions. I can solve most graph theory problems but, when it comes
to those other 2 topics, it is up to chance if I can recognize a solution and solve it. Overall, it was a fun time and I'm thankful it is over so I don't have to stress about
preparing anymore.

Tips:

• Talk as you code. I think it helps guide you and the interviewer to the solution you have in mind. If you are going to stop writing one part of an algorithm to work on another, say so.
• Learn how to identify what kind of problem you are working on and what data structure it relies on. Even if you don't know how to solve it immediately, It might come to you as you code up the basic structure/algorithm
• It is really difficult to explain your approach in a virtual interview without something to draw on. If you can draw on a small whiteboard or paper and hold it up, it could help. If not, try typing and using examples
• Explain what you are going to do to solve the problem. Even if you don't finish, you could get points for communication.