FB, MSFT interview: Case study

Here is the article. 

Hello everyone, I got multiple good questions asked in my interview experience with Microsoft and one of the requests was to provide a summary of my preparation journey. There was a time (couple of years back) when writing a iterative pre-order traversal of binary tree, or even a basic stairs dynamic problem used to be a daunting task for me. Then I accepted my current situation and came up with a plan to improve my coding skills and system design skills which I will share with you along with my learnings during this journey.

Micorsoft Interview Experience (just in case you missed it) :
https://leetcode.com/discuss/interview-experience/1260613/microsoft-engineering-manager-hyderabad-may-2021-offer/969476

Before I start, I would like to thank the entire LeetCode Community for all the help and encouragement over the last few years for the interview preparation.

Familiarising with basic algorithms and data structures

Coding Book I followed - The book which was highly recommended to me was Cormen and I quickly glanced thorugh few chapters and I realised though this is an excellent text - it is not suited for improving my coding practices. I was looking for some book which would explain the concept and also have a working code in some languages (preferably C or Java) and after exploring around 8-10 books I narrowed down to the following:

1. Algorithms (4e) - Robert Sedgewick
2. The Algorithm Design Manual - Skienna
3. Elements of Programming Interview - Adnan Aziz

If you want to know all the books that I explored then let me know in the comments. I have a small library where those books are still lying peacefully :D.

I learned the basic implementation of Heap, Trie, Graphs and their traversals, Dynamic Programming and its basics, Stack and Queues etc. from the first book. I also referred second book time to time. Once I had learnt all the basic implementation of all the data structures and classic algorithms next step was to solve some problems.

And for the problem solving I explored the following books:

1. Elements of Programming Interview (Java edition) - excellent choice as the number and quality of problems is good and explanation is also very good.
2. Cracking the coding interview - descent book but the quality of problems is not great IMO. It may be an excellent book few years back but now its just okay.
3. DS and Algo made easy - poorly written book with some random code samples collected together without any continuity and explanation is almost non-existent. Please avoid this book.

Coding Platform I followed - I explored hcker-rank, hcker-earth, gek-for-geks(G4G) and leetcode. My experience is that first two platforms will have lengthy description of the problem before coming to the real problem and that was frustrating for me because of the time I was wasting in reading that huge description of the problem. The G4G was having too many problems and majority of them are not well defined, solutions not well explained and absolutely no categorization of the problems and solutions - same problem repeated multiple times with different solutions and zero organization. So I did not use any of those platforms any longer.

I was quite impressed with the quality of the problems in leetcode. Also it was also highly recommended by some of my friends in Google/FB/MS and hence I followed only one platform and that is leetcode. The first thing after that I did was to get subscription of premium as that is highly useful. You can have five sessions under one subscription.

========================== Fun Begins Now ================================

Phase 1 - Baby Steps
In the beginning, I focused on easy questions to gain confidence and get some consistency. Once I overcame the friction of doing questions, I moved onto the medium and hard questions. I followed 60-30-10 rule where 60 percent of the problems I solved were easy, 30 percent were medium and only 10 percent were hard.

How did I select those problems? The answer is I divided the problems into multiple topics and for each topic I targeted the problems which were asked in companies (locked problems which can be seen if you have premium) and the commonly asked problems in interviews (as discussed on leetcode community). In phase one I targeted the following topics:

1. Sliding Window
2. Two Pointers
3. Array problems (Search, Sort etc) - mastered Binary Search also
4. Tree based problems (Binary Tree and Binary Search Tree only)
5. Stack and Queue based problems
6. Heap problems

I also referred to a link (cannot locate it) for dividing problems on basis of topic (similar to the below link):
https://leetcode.com/discuss/career/448024/Topic-wise-problems-for-Beginners

Note: Whatever problems I solved I kept all my learning and solutions in a word document which I could refer whenever and wherever I want. This is very important in case you want to revise any concept or a problem in future.

You will get an urge to see the solution during early phase esp - but do not look at the solution until and unless you are sure that you have tried all your ideas. If you have tried all then look at the solution, try to see what did you miss and do keep that in mind. Also even if you have solved the problem and it is accepted - do check the discuss tab and look for top 5 or top 10 highly voted solutions. I have learnt a lot from them.

Phase 2 - Trying to Stand up
In this phase I targeted the topics which were slightly difficult to grasp:

1. Dynamic Programming
2. Backtracking
3. Divide-And-Conquer
4. Graph problems

I took the help of tags here e.g. for graphs we can use the link: https://leetcode.com/tag/graph/ and then I sorted the problems on the basis of frequency and started targetting the most frequent problems (imo this is a premium feature). I spend a lot of time in understanding the underlying concept of graph traversals, how they relate to tree traversal e.g. similarity in BFS of graph and level order traversal of tree, how and why we use queue for BFS, how and when we can use stack in graph traversal, topological sort, pattern of backtracking - a result container which would store the value from temp, conditional return of temp, exploring paths, and backtracking by removing last item in temp etc. I divised some of my own patterns for backtracking and other areas and then I tried to reuse them into different problems.

Phase 3 - Trying to Run Now
In this phase I tried to solve all the locked problems (asked in companies), also mastered many patterns till now so used to revise them timely, also checked out top questions asked in leading companies like Microsoft, Facebook, Google etc. and tried to solve them. I focussed on some tricky topics:

1. Intervals based problems
2. Segment/Fenwick Tree
3. Union Find (Connected Components)
4. Hard Miscellaneous problems

I realized though I could solve easy problems most of the times and medium problems some times, I was still struggling with hard problems a lot. Some problems never crossed my mind even after spending 5-8 hours and that was hurting me a lot. So I changed my stratgey to focus on the problem for 20-30 minutes and if I could not make progress I will check the solution (and also the discuss tabs for most voted solutions) and will try to understand the solution and then keep the learning in my notes - which I would revise time to time.

It is very difficult to get time for coding practices esp when you are working so I used to take 30-40 minutes in morning where I will read about a problem, will brain storm to find the solution, used to discuss sometimes with my like minded peers, and will see the solution if I eventually give up. I used to address problems from diverse topics so that I wont loose the interest and also it is more effective stragetgy imo.

Try to solve a problem using multiple concepts
I used to try solving a problem using multiple ways and then try to compare complexity and other aspects.

Try to figure out if a problem can be mapped to a more commonly asked problem and use that solution.
This has been a good learning where I learnt how to solve a classic problem and then during my journey realised that multiple problems can be mapeed to same problem. For example 960. Delete Columns to Make Sorted III and 354. Russian Doll Envelopes are very similar to the problem 300. Longest Increasing Subsequence and solution for that can be reused to solve other two problems as well.

Do not spend too much time on a single problem
I have solved 300+ problems and this is what I learnt. Always try 10-15 minutes in a problem to find the pattern e.g. check if it needs exhaustive search (may be we can use BFS), or it needs backtrack, or it can be solved by DP after we have explored and sovled for multiple given inputs etc.
If the pattern is too obvious then sometimes I skip the problem to focus on other problems.

Keep eye on locked and tricky problems
Always look out for problems which have some tricks underlying them - IMO they have high chance of being asked in upcoming interviews.
I recommend to take the leetcode premium subscription then you can also unlock the locked problems and articles. You can have five active session in one subscription and can share with friends to share cost.

Phase 4 - System Design
Honestly I have been designing systems in my current job profile so I did not spend too much time on this. But I still found the following materials useful for my preparation:

1. Course Gr**** the System Design Course from Ed**** (Sorry for the * as LeetCode does not allow me to write those words in the post. I hope you can guess the course) very useful. This course is highly recommended and is worth it.
2. Famous System Design Primer on Github
3. Articles on high scalability - Highscalability.com
4. Posts tagged under System Design on LeetCode Discuss - https://leetcode.com/discuss/interview-question?currentPage=1&orderBy=most_votes&query=&tag=system-design

There are too many youtube channels having system design videos - imo they are mostly useless as they are not comprehensive and some of them are even plain wrong about the design idea. I suggest to follow official videos from various companies, infoQ videos, Facebook Developers videos etc. They are really useful to get that final feather in your hat!

I would like to conclude this with some interesting links:
https://leetcode.com/discuss/career/449135/how-to-effectively-use-leetcode-to-prepare-for-interviews
https://leetcode.com/discuss/general-discussion/665604/Important-and-Useful-links-from-all-over-the-LeetCode
https://leetcode.com/discuss/general-discussion/494279/comprehensive-data-structure-and-algorithm-study-guide
https://leetcode.com/discuss/general-discussion/459286/Best-Posts-of-2019
https://leetcode.com/discuss/general-discussion/522705/1000-leetcode-problems-within-a-year
https://leetcode.com/discuss/general-discussion/458695/dynamic-programming-patterns/544912

=============== Books I explored ================
Some of you are showing interest in the books I explored so I have listed them below and rating is as per my opinion(rated out of 5):

Algorithms Prep
Algorithms 4e(4.5) - excellent book for algorithms and DS
Algorithm design manual (4) - very good
Cormen (4) - good text book but voluminous and more for academic and research
DS and Algo made easy (2) - poor book so avoid it. Its more of a collection of random code samples without any continuity. Too many coding errors and poor explanation.
Algo in a nutshell (2.5) - descent for overview of algo
DS by Lafore (2) - text book kind of not much useful
DS by Weiss (3) - text book

Problem Solving
Element of Programming Interview (4.5) - excellent book for coding prep
Cracking the coding (3) - descent book for coding prep
Programming Interviews exposed (3) - okayish book

Coding Practices
Clean Code (4) - excellent book
Clean Coder (3.5)
Programming Pearls (4) - just covered half of the book only

Architecture
Clean Architecture (3.5)
Design Patterns by Gamma (4) - classical text
Patterns of Enterprise app architecture (4) - great book by Fowler

System Design
Designing Data-Intensive Applications (4) - great book but takes time to cover everything
Gr***ng the system design (4.5) - excellent choice

githubmicrosoft

Google interview: Case study

March 9,  2022

Here is the article. 

Experience: 2 years
Position: L3 (Software Engineer)
Location: Bangalore, India
Offer Date: July, 2020

I would like to give huge thanks to Leetcode and the community. Without Leetcode and the community's help, this offer simply would have been less likely.

I was contacted by the Google recruiter around last week of March through Linkedin. I got a call from the recruiter around April first week to begin with the interview process. Since I was completely out of touch, I asked for a month time to prepare for the telephonic interview. However the recruiter gave me 2 weeks of time to prepare for the telephonic round, and told that he will give me 1 month extra time to prepare for the onsite rounds once the telephonic round is cleared.

Preparation for telephonic round
The recruiter shared the bunch of resources and guides to prepare for the coding interviews. Before this, I was very inactive in Leetcode and I used to sporadically participate in the Leetcode's weekly contests. After the call with recruiter, I started prepping more aggresively in Leetcode for the next 2 weeks for my telephonic interview. I solved roughly around 125 problems (25 easy, 80 medium, 20 hard) in the 2 weeks time, covering the most common topics like Trees, Graphs, DP, arrays, binary search, etc.

I have had the access to my friend's premium Leetcode account, where I mostly practiced the Google filtered medium-hard level problems. I also completed all the Google phone interview mock interviews from the premium account. I also managed to solve most of the problems from the featured 'Get well prepared for Google Interview' explore card available in Leetcode premium. I was practicing writing code in Google Doc, which really helped me simulate the real interview process.

Interview Process

Telephonic Interview (45 mins)

The interview was scheduled to happen in the mid week of April, but it got rescheduled twice, firstly the interviewer did not appear, and the second time the interviewer mentioned there was lot of noise in his place, and asked to reschedule the interview. Finally, the interview was scheduled for the last week of April.

The interviewer asked me quite straight forward easy-medium array problem based on the binary search. There were two parts of the problem, the first part being just the straight forward implementation, while the second part requiring the binary search to solve.

I solved both the parts of the problem quickly, along with the dry run of some examples and explanation in around ~30 minutes. Then the interviewer asked me the big O complexity for both the solutions and asked me to think of some test cases. I wrote down around 10 different test scenarios for the problem, along with their expected output. We were still left with roughly around ~5 minutes, I asked him a few questions.

Virtual Onsite Interviews

After about an week, I followed up with my recruiter regarding the feedback of my telephonic round, and the recruiter told me that the feedback is not yet updated in the system and will let me know once the feedback is updated. Almost after a month (around 3rd week of May), I got a call from my recruiter saying that I have cleared the telephonic round and they are heading towards my virtual onsite interviews. He briefed me about the virtual interview process and asked me how much time I would require to prepare, so I asked him for a month time to prepare. The onsite interviews were scheduled for mid week of june. He shared few resources and tips to prepare for the interview.

Preparation for Virtual Onsite Interviews

The preparation for the onsite interviews were almost similar to that of the telephonic round, except that I had more time to prepare and I could solve lot of problems. I started participating actively in the Leetcode's weekly contests and upsolve the problems from the past contests which I had missed. I also started participating in the Leetcode's monthly challenges.

The result of telephonic round took almost a month, so I was prepping during that time as well since the interview had went really well and I was quite sure about moving to onsite. I solved roughly around ~300 problems in 2 months time, which consists roughly around 30 easy, 200 mediums, and 70 hard problems covering most of the important topics like Arrays, graphs, trees, DP, greedy, recursion, binary search etc. Apart from these, I also completed all the Google Onsite Interview mock interviews from my friend's premium account. I completed all the problems from the featured 'Get well prepared for Google Interview' explore card available in Leetcode premium. I use to write the code in Google doc, initially it was tough but after writing a lot of codes in doc, it became cakewalk and and most of them would get a clean AC verdict when copied and pasted to the Leetcode's beautiful editor!

Technical interview 1(45 mins)

The first problem was based on the binary tree, and the difficulty of the problem was Medium. I spent around 5 minutes to understand and rephrase the problem, and after brainstorming the next 5 minutes, I came up with an approach and shared it to the interviewer. He agreed upon the approach, and asked me to code. I spent around 15 minutes (too long) to code the solution. I walked through the code with the sample inputs and started looking for the off-by-one-errors and the other bugs. The code was working fine and the interviewer moved on to the next problem.

The second problem was also based on the binary tree. I quickly came up with the solution in < 5 mins, shared with the interviewer, he agreed and asked me to code. I coded it up in around 10 mins, and walked through some same inputs and it worked! We were left with roughly 5 mins, and I asked a few questions to him related to Google.

The interview ended with the interviewer telling me that I did a good job and wished me good luck for the other interviews.

Technical interview 2(45 mins)

The first problem was a medium problem. I gave him 2-3 approaches to this problem, and he asked me to code the dynamic programming based approach. I quickly coded up the solution, and we were done with this problem within 20 minutes of the interview.

The second problem was about designing and implementing few methods in a class, the difficulty I'd say was medium, and it required the knowledge of heap / priority queue to solve it. I discussed the priority queue based approach with him, he agreed and I quickly coded up the solution. He asked a few questions or follow ups which I was able to answer pretty quickly as well.

We were left with 5 minutes, I asked him a few questions and I could clearly see that the interviewer was really impressed. This was my best round so far, and I heard from my recruiter that I got a very good feedback from the interviewer.

Technical interview 3(45 mins)

The problem was based on the binary tree. I discussed the approach with the interviewer, he agreed and asked me to code it. I quickly coded it up in < 5 mins, and while I was looking for off-by-one-errors, I found a small case which was not handled in the code, I fixed it. Then we walked through the code for a few sample inputs, and it worked. He asked me if there are any optimization areas in the code, I did a few optimizations (case eliminations), although the time complexity would not change. The interviewer said the solution is correct and optimal, and asked me the time complexity. I struggled a bit while answering the time complexity, because it was not quite trivial, eventually with some help from the interviewer, I was able to come up with the correct time complexity of the code.

Since we were left with 25 minutes, I was expecting another question, but the interviewer told that he would be asking few follow ups on the same question. He told that the solution I have provided is the most optimal solution in terms of Algorithmic view, and we can not further optimize it, but if we have to solve this same problem for large scale systems, then we can not afford to have O(N^2) solution, so he asked me to come up with something approximate / heuristic solution which is close to the correct answer and would run in a linear time.

I initially proposed a very basic random approximate solution, which would run in linear time but it was not very accurate. He asked me to optimize the accuracy, I proposed another solution, he asked me to further optimize it, like this way, I gave him around 6-7 different approximate based solutions, after continuous iterations. He finally said that we have reached the accuracy to very good extent, and this should work for most of the scenarios, and we need not optimize it further. We were left with some time, and I asked a few questions to him. The interview ended 5 minutes early.

Technical interview 4(45 mins)

The first problem was based on the binary tree. There is a binary tree root pointer given, we need to check if for every node in the tree, the absolute difference between the sum of all the nodes in the left subtree and the sum of all the nodes in the right subtree satisfies some given condition.

I shared the linear O(n) recursive solution with him, and he agreed with that approach. I coded the solution and we walked through the code for a few sample inputs, and it worked. He also asked a few counter questions related to the code, to which I was able to answer all of them. The interviewer asked if there are some optimizations possible in the code, I did a few obvious optimizations (case eliminations), but that would still not change the time complexity. He agreed and we moved on to the next problem.

The second problem was a medium problem based on strings to check whether the answer exists or not. I did brainstorming for some time, and was able to come up with the linear O(n) solution. I shared my approach with him, and he raised a few counter questions on my approach, but I was able to resolve them by trying out the approach on some examples, he agreed and asked me to code it. I coded up the solution in ~7-8 mins, we walked through few sample inputs, look out for off-by-bit errors, everything was fine.

Next, he asked the follow up for the above problem, that now we also want to return one of the possible answer if the answer exists. I discussed him the linked list based approach to construct one of the possible answers, he agreed. Although, he did not ask me to write a code for it. We were still left with some time, so I asked him a few questions on his recent projects in Google. This was also one of the best rounds I have had so far.

Non technical interview

After a few days, I got a call from my recruiter saying that I have received very good feedbacks from my coding interviews, and the next round is the Googleyness round. He shared some useful docs and guides to prepare for it. I asked for 1 week of time to prepare it as I really wanted to crush it.

Result

After a few days, I got a call from my recruiter saying that I have received above average feedback from my googleyness round, and they are moving ahead for the Hiring Committee round. The recruiter asked for the internal references from the Googler whom I know. I got a really really strong internal reference from my friends who are working at Google. After a few days, I got a call from recruiter saying that the HC has requested for 1 more additional coding interview. The recruiter told me to practice the hard problems, so I took 1 week of time for preparation, and practiced the Googled filtered hard problems from Leetcode. I solved around ~40-50 hard problems in 1 week of time, and revised some of the problems which I solved in the past during the onsite round preparations.

Technical interview 5(45 mins)

The problem was based on the Graph theory. The problem was definitely hard, and it took me quite a while to come up with the most optimal approach. I started with the brute force approach, to check and find every possible candidate answers, and find the optimal one.

After thinking for a while, the optimal solution clicked on my mind, and I shared the approach with the interviewer, he agreed and asked me to code it up. I took around ~15 minutes to code the solution, and explain it to him, with some sample inputs, and while we were walking through the code, I found a major bug in the code. I quickly fixed it as soon as I discovered it, and then we again walked through the code, and this time it worked. The interviewer agreed, and asked for the time and space complexity of the solution. As I spent a lot of time while explaining the approach, so we were hardly left with few minutes, so he could not ask me second question. He asked me if I have any questions, so I quickly asked him one question related to the Google.

Result

After 2 days, I got a call from my recruiter that the hiring committee has approved my packet, and that I have received very positive feedback from my last round. Then he told me that the next is Offer Review Committee, and asked few details regarding my current compensation, any other offers etc. The Offer Review Committee approved the packet, and I finally received the offer letter in my hand.

Time Management Strategy

The time managment strategy that I followed was,

1. Solve the first problem within 20 minutes including code.
2. Solve the second problem within next 20 minutes including code.
3. Five minutes buffer for the general discussions and Q/A.

Break down for 20 minutes to solve the problem,

1. 5 minutes to understand the problem and clarify all the doubts
2. 7-8 minutes to come up with the optimal solution.
3. 7-8 minutes to code the solution.

I'd advice to take some extra time but come up with the most optimal solution you can, in the first shot, rather than spending time on the non-optimal or brute force approach, as Google will focus mostly on the optimal solutions.

Advice and suggestions

Apart from the intense preparations before the interview, one thing that really really helped me and I would really like to suggest is to do some meditation before your interview, so as to relax your mind, which will increase the productivity of your brain during the interview.

I use to listen to this below 12 mins coding interview meditation, approximately half hour before my interview which does the positive visualization exercise where we visualize the day of the successful onsite interviews and it really helps to maintain positivity throughout the interview.

https://www.interviewcake.com/coding-interview-meditation
https://www.interviewcake.com/24-hours-before-onsite-whiteboard-coding-interview

Facebook interview: Case study

March 9, 2022

Here is the article. 

Facebook [OFFER - ACCEPTED]

• Position
  • Rotational Software Engineer
• Application
  • Interviewed with FB in 2018 and got rejected. Recruiter followed up with me a year later and asked if I was interested in interviewing again. At the time I wasn't but then several months later I followed up with that recruiter and was able to schedule a call to start the interview process again
• Stage 1: Call with recruiter
  • Quick and straightforward conversation about the position, the company, my background/experience, and the interview process
• Stage 2: Tech Phone Screen
  • Coding Challenge 1
    • "Easy" level leetcode question
    • Return the sum of an array that contains either numbers or other arrays of numbers, and multiply the total of each array by its nested depth
  • Coding Challenge 2
    • "Medium" level leetcode question
    • Given a string with alphanum characters and open or close parentheses, remove the minimum number of parentheses necessary to ensure all parentheses correctly close (only "(" and ")" are used, no brackets or curly braces)
• Stage 3: Virtual Onsite
  • Interview 1: Coding Challenge
    • Challenge 1
      • Write a function that accepts an array of numbers and returns the length of the longest monotonic subsequence
    • Challenge 2
      • Write a function that accepts a tree and returns the length of the longest path between any two nodes
  • Interview 2: System Design
    • Problem
      • You're working on a music streaming app. How would you build a feature to show users their top 10 most-played songs each week?
      • Interviewer had follow-up questions, and also asked about things like how to measure the feature's success, and what other similar/related features can be built on top of this
  • Interview 3: Behavioral
    • Was asked several behavioral questions about how I would handle a certain scenario or to talk about past challenges/successes
  • Interview 4: Coding Challenge
    • something like leetcode #460 - subarray sum equals k
• Interview Result
  • Received offer for Rotational Software Engineer E4
• Interview Experience
  • Extremely Positive
  • Recruiters were outstanding
  • Interviewers were really experienced
  • All of the discussions felt like real, down-to-earth conversations, as if we were working a problem together
  • FB was my #1 choice so I accepted the offer and then declined my other offers/candidacies

Google interview: Case study

 Here is the article on Leetcode.com

Google [was in hiring committee stage]

• Position
  • Software Engineer
• Application
  • Google recruiter cold-messaged me on LinkedIn like 6 months earlier, when I wasn't interviewing
  • I followed up with that recruiter and was able to go directly to an onsite interview somehow
• Stage 1: Call with recruiter
  • Quick and straightforward conversation about the position, the company, my background/experience, and the interview process
• Stage 2: Virtual Onsite
  • Interview 1: Coding Challenge
    • Coding Challenge
      • Write a function that takes an array of words and returns their shortened letter-count version, i.e. ["google", "word"] => ["g4e", "w2d"]. If the shortened version is not unique, expand out 1 letter at a time
  • Interview 2: Coding Challenge
    • Coding Challenge
      • The question was a real-world application of weighted Dijsktra's algorithm
    • Coding Challenge Result
      • I made the mistake of not practicing Dijsktra's algorithm, so I pretty much bombed this round, but I tried to fail as gracefully as possible
      • Tried to rack up points on the parts of the problem which were more general math, and then I just kept asking questions, including questions about how Dijkstra's algorithm works
      • The interviewer was nice and answered all of my questions where possible, which helped me feel less embarassed/incompetent
      • The prep materials said to practice Dijkstra's algorithm but I ignored it because i was like, "nah i doubt they would ask that during a 45-min interview", and lo and behold. Moral of the story, study EVERYTHING on your guide (whichever study guide the company gives you)
  • Interview 3: Coding Challenge
    • Coding Challenge
      • Something about tracking when RPC calls were made and detecting when a particular call exceeds the timeout threshold
  • Interview 4: Googlyness
    • Was asked several situational behavioral questions
  • Interview 5: Coding Challenges
    • Overview
      • Was asked 1 coding challenge, and to discuss the start of a second technical challenge
    • Coding Challenge 1
      • Don't remember the exact problem, but something related to taking an array of numbers and a target number, and then rotating the array upon the target number without changing the original order
    • Technical Question 2 (no coding)
      • Given a map as a square, and a set of locations on the map, users are able to select a rectangle on the map and all of the locations on the map are returned
      • How would you preprocess the map data so that the find operation for the locations in the inner rectangle can be done in less than O(n) time?
• Interview Result
  • Feedback on my performance was mostly positive, so I made it to the hiring committe stage. At this point, the HC decided that because of my poor performance in the second interview but strong performance in the other rounds, they wanted me to do two more 45-min interviews focused on front-end and JavaScript (since JS is my strongest language)
  • While waiting to schedule the additional two interviews, I started the team-matching process and met with a team that I ended up feeling really strongly/positive about
  • Shortly before my interviews, however, FB made me an offer, and that was my top choice so I accepted FB and ended my application/candidacy with Google and thanked them for the great opportunity and experience
• Interview Experience
  • Very positive
  • Recruiters were outstanding
  • Interviews were challenging
  • I enjoyed the engaging feedback from the interviewers during the coding challenges

Leetcode: Lee215

 https://leetcode.com/lee215/

My hobby

I really love to practice hard level algorithms, and I also like to explore different ideas from top players, and then copy idea and write C# practice in less than 15 or 20 minutes for those hard level algorithms. My favorite players are Lee215 and a few others. When I have free time, I always like to try some new ideas, specially hard level, try at least three top voted discuss posts, and I really like to advance my C# coding skills.

I like to go over solutions written by Lee215 and then write down a few things to learn. 

Leetcode blog: AMZ | Google | Facebook | Offer | Reject| Reject | My journey from failure to offer at FAANG

March 9, 2022

AMZ | Google | Facebook | Offer | Reject| Reject | My journey from failure to offer at FAANG

Here is the article.  

The final piece in the plan was getting some real world checks. If you just study by yourself, even though you are solving things to your satisfaction, there is absolutely no guarantee you will succeed in a real interview, with all the surprises, and time pressure. The same way a marathonist will perform some preliminary short races before approaching the big race. Or a fighter sparring at the gym.

I started booking mock interviews. I first tried p-r-a-m-p. Here you take turns to interview a fellow engineer on a problem provided by the platform. This helped in getting a reality check. But I wasn't very happy with the interviewers. I was feeling that most had no experience interviewing nor understood what signals to look for in candidates. So feedback was not that great.
I then tried i-n-t-e-r-v-i-e-w-i-n-g-.i-o Here I felt I met my match. I was consistently failing on all mock interviews. Not only on problem solving but also on timing. I started getting a little desperate and discouraged.

So I adjusted my plan again. I took a break from mocks and focused on timing. I used the L.C. mock interview feature. First thing in the morning I would do, was take one or two L.C. mock interviews. That was tallying a consistent 4 easy to med problems just in the AM.

I also noticed that there were some emerging patterns in most of these problems. Even though in an ideal world, you shouldn't attemp to just "pigeon hole" a problem to a pattern, I felt that given the time constraints and nature of interviews, trying to narrow down to patterns was a good strategy. This was also confirmed by a session I had with a real Amazon engineer on a mock interview I got from g-a-i-n-l-o . He basically told me to structure my training to these timing milestones:

• 10 minutes, clarify assumptions, edge cases, define method. Define pattern:
  • straight forward
  • BFS / DFS
  • Flood fill
  • Brute Force
  • Backtracking
  • D.P
  • Greedy
• 10 minutes come up with a brute force solution.
• 20 minutes, code
• 5 minutes, test

Those milestones were also corroboarted by some passages of Gayle Lackman's "cracking the coding interview"

To learn more about patterns, I purchased also from e-d-u-c-a-t-i-v-e the "Patterns for coding questions". It was very helpful (although not full-encompasing and must be taken with a pinch of salt).

Closing Thoughts and recommendations:

If you made it up to here, I really really apreciate you took the time to read about me. Sorry if it was too long.

• Have a plan. Put clear milestones. Clear objectives. Clear Dates.
• Be willing to adjust your strategy several times during your journey
• Measure yourself.
• Don't be foolish. Don't assume you'll wing it. Be honest. Identify your shortcomings. Work on those.
• Get reality checks. Get out of your comfort zone. Do those mock interviews. Get used to the uncomfortable interviewers. Get used to the disapointing feedback. It WILL make you stronger.
• Be disciplined. Be consistent. Write down your progress. So you can see that you ARE in fact moving forward.
• Reward yourself. Be kind. This shit is hard. Very hard. You deserve rewards for your hard work. Take a few minutes to watch some silly youtube. Go to the coffee shop (or order online if social distancing) and get that pastry.
• A very very small percentage of the engineers at FAANG are Alan Turing kind of geniuses. The rest are guys like you and me who most probably failed 2, 3 or 4 times until they got the gig. They went through the exact same journey you did.
• Force yourself to solve problems before looking at solution. But put a reasonable time-limit. Say 2 hs. 1.5hs... then look at solution, take notes of what you learned.
• L.C. community is pure gold. You'll find invaluable explanations, patterns and workarounds.
• DO contribute. Even if your solution does not seem great, do post it. Try to add explanations. This gets you into the mindset of communicating and explaining why your solution works. Plus, if it sucks, you might get the gift of feedback from a fellow Leetcoder.
• Narrow down your coding options. If your language has 10 ways of accesing a hash map, focus on the one or 2 that fit most cases. Same for other coding structures (loops, conditionals, etc..) This will save you time.
• Take note of patterns and try to memorize them. Level order BFS traversal should be a no-brainer and you should be able to code it with your eyes closed. Same for Initializing a hashmap with frequency of occurrence counts. Or a BFS for exploring adjacent cells on a matrix. Or iterative Binary search and it's many cousins...know them by heart and be able to invoke them on a moment's notice like a Pokemon Master.
• During interviews, make sure you are giving interviewer the signals they are looking for. Try to manage time well. Ask them "how are we doing with time". Ask good probing questions "Does this approach sound good? Should we code this?"
• Try to get a brute force approach first thing. If you can't optimize, at least you can code that and interviewer will know how good your code is. The outcome might be "weak hire" vs "no hire".
• Placeholder methods are your friend. Specially on tight time. If your algorithm requires initializing an MxN array of distances, just abstract that in a method, put the placeholder signature, let your interviewer know what it does and that you will code it later and keep moving! Most probably the backtracking method that will follow is the most important piece that the interviewers are looking for.
• Don't underestimate testing your code. Always do it. Start with small inputs and simple cases. Then consider edge cases and expand to more complex ones. Go line by line. Pretend you are the IDE debugger and update variable values as you go. Demonstrate that your thing actually does what it claims.
• On system design, don't just read the hell out of everything. Practice whiteboarding solutions from scratch. Reason and talk through them. Just like with your L.C. grind, try to get sys design each day. Ask yourself why 5 times, when deciding on a given db technology, a parition key, a given db index, realtime vs async, etc... You need to be able to justify your decisions and your case has to be bullet proof.
• Behavioral: Use STAR format. Put on a doc your whole work history. Then isolate individual situations, projects, successes, failures. Make a story out of each.
• That last point is specially important for Amazon and their leadership principles.
• Luck can be a big factor. So don't put all your eggs in one basket. Maximize probability of succesful outcome, by getting lots of interviews, strategically timed out.
• Don't give up.
• Don't beat yourself. You are amazing.