How Meta helped me get into Google!
Come Summer 2022 and I will be a Noogler for a minute. And I have Meta to thank for it.
I want to tell you that it is certainly possible for anybody, without spending serious money on interview prep, to get into FAANG (at least as an intern). The secret to making it through these interviews, and maybe even blowing them out of the water, is practice. Not sheer “Leetcode grinding”, but practicing core patterns and their variations for common data structures like graphs (BFS, DFS, tree traversals), arrays (two pointers, three pointers, sliding window) and even dynamic programming (mainly storing states and moving through them). Practice till those patterns become second nature! Quoting my first boss,
you should be able to do it over the phone, groggy from being awakened at 3 AM in the morning
A lot of times we read about or watch a solution or a technique and think we understand it. I learnt the hard way, during the Meta interview, that it is not necessarily the case. The hard truth is that commoners, like you and I, need to grind the algorithms, techniques and solution approaches till they become muscle memory (which is entirely different from memorizing 500 problems which is not what I am suggesting). As an example, if you look at my Leetcode profile, you will find that I solved 33 “Easy” problems and 27 “Medium” ones by the time I appeared for Google with a 42% acceptance rate. But when you look deeper, you will see that I solved some of those problems many times figuring out what works and what doesn’t in the process.
Why am I writing this article
Mainly I am writing this blog, and hopefully a series discussing specific techniques and algorithms and Leetcode problems that I consider to have a high learning entropy, because:
- I want to show that getting from novice to acceptable is possible in a couple of months. Mastery might be achieved if you have slightly more time.
- Point out good and free resources and possibly a roadmap.
- Improve myself to a point where I can really ace these interviews.
- Most importantly, I want to help cash-strapped students like me.
It took me a tad over two months to prepare — between the Meta and Google interviews. And in that time, I became very familiar with techniques involving arrays, trees and linked lists along with gaining significant familiarity with backtracking and dynamic programming. Most importantly, I didn’t spend a dime on my preparation (except for a $30 system design course from the authors of the system design interview book; and my advisor bought a few books on my recommendation to help future lab student prepare better for interviews — system design material is harder to find for free).
My interview experiences
In early November 2021, I got an email from Meta asking if I would like to interview with them. I had not applied, so was suspicious at first which gave way to ecstasy and I, of course, agreed. I studied hard for the next two weeks till my interview and failed harder. I bombed the first interview completely. I didn’t see that the first question was asking for a BFS solution, though I got there with a couple of hints. The next question was also reasonable but I panicked and froze up and did not complete it (I think this question ultimately cost me the Meta internship). So despite the next interview going rather well, I was rejected (or maybe there was another reason that I don’t know).
In hindsight, the pattern at Meta is to solve two Leetcode type problems within 45 minutes ending with runnable code. They don’t ask you to actually run the code though. The first question is “LC Easy”-ish and the second one is “LC Medium” where the medium difficulty problem is not too tough either. The general consensus seems to be that Meta emphasises your coding proficiency whereas Google cares more about your problem solving (both care about strong and well-rounded skills, just emphasises different ones). At the time of the Meta interview, my coding ability was on the weaker side (and it took some practice for me to even realise that). By Google, I had reached a point where I could code up basic patterns and their variations on common data structures without making too many mistakes.
Anyhow, after Meta I got an interview with Snowflake which was a coding assessment on HackerRank. This was a lot harder than I expected — 3 problems in 90 minutes with 2 of them being on DP and Bactracking. I didn’t pass this one. Next I appeared for an online assessment from Netflix on CodeSignal. I passed every but two hidden test cases on the last problem and received a 788. Online forums tell me that people tend to get an email from Netflix even if they were rejected but I have not heard back (two month since at the time of writing). The whole thing felt a little harsh and terribly impersonal to me, but it is what it is.
Finally, I appeared for the Google interview. It was a bit different from the others so far, but very similar in structure and ordering to an Uber interview I appeared for back in 2020 (Uber never let me know if I cleared before they withdrew the position). However, if I am to believe online blogs then the similarity between the Google and Uber interviews is purely coincidental (they were uncannily similar nonetheless).
With Google, as it had been with Uber, the first interview was a coding interview. The specification was quite clearly spelled out and I felt that the interview was primarily geared towards watching me write code. I made a mistake where I did not check for the existence of a key before accessing it in a hash table. The interviewer told me that I had a bug and presented a test case that allowed me to figure out the bug. The second interview is an algorithmic interview. We had a little discussion before the actual interview started. During the Uber interview back in 2020, I remember thinking that the problem was interesting but not intimidating. However, at Google the data structure was nothing like anything I had ever seen before (later I did figure out what it is but ultimately that did not matter). It was probably not difficult in hindsight but quite involved at that moment. The interviewer presented me with two questions upfront and informed me that he was going to ask a total of 4; and it was up to me to manage time. Coding and explaining the solution to the first two questions, talking about the time and space complexity and the initial discussion took up around 30 minutes. Once the third question was posed, I was lost. I could think of a solution but not how to code it up — again not too hard in hindsight. One advice I have here for myself and others, is that it might be worthwhile to think of and write down the cases that need to be handled to get to a solution. I was under pressure fighting the clock and panic started to set in once again; so I stepped back and presented a brute force solution that repeatedly called the function I had already written, giving myself some breathing room. From then onward, it was a back-and-forth discussion between the two of us till I managed to code up an optimal solution at the fag end of the interview. I tacitly asked both interviewers how I performed. While the first interviewer skirted the implicit question politely, the second frankly told me that most people don’t finish all four and I did “great”.
Interestingly, a very common advice I saw everywhere is that while interviewers do not care about simple syntactical mistakes, they are gravely concerned about non trivial ones. During the first Google interview, I wrote something like isinstance(elem, string) multiple times. And only after the interview, did I realise that mistake. However, I do believe that I had otherwise demonstrated a very strong understanding of programming and Python which saw me through.
Anyhow, about two weeks later I received an email from my recruiter that read, “Deep Bhattacharya — Good News from Google!”
My Takeaways
- The interviewer is your friend. Talk to him/her, explain what you are doing and why clearly or if you need to clarify certain APIs. This allows them to help you if you get stuck. You will get stuck and then they will step in, if they know what you are thinking. Listen carefully when your interviewer is telling how to approach the solution. I missed out on this in a big way during the Meta interview.
- Practice, practice and practice your coding in whatever language you prefer. If your brain starts panicking during an interview, like it happened to me, then your muscle memory should take over and implement whatever pattern is the need of the hour. Plus during the interview, you shouldn’t have to think about the coding, for example whether your linked list has an odd number of elements when your fast pointer is null, saving you precious time. Knowing you can do something correctly all the time is a huge confidence booster too — all you have to do then is build a solution stringing patterns you already know together.
- If the interviewer is telling you something completely different from your approach then drop your approach and follow his/hers. Sometimes, your approach may be just as correct but it might be that the interviewer is looking for something particular. Even if you are really convinced that you know better, you simply don’t have the time to convince them in the general case. But there is also a good chance that you are plain wrong and are heading for a disaster. So take the interviewer’s advice even if you don’t understand or even agree with it at the moment.
- When practicing on Leetcode or any other platform try a few variations of the problem at hand, if possible. For example, if you are printing or returning one element while traversing a graph/tree, try to figure out how you would return a subset instead of just one element! Not practicing this one bit me during the Google algorithm interview. I eventually got it but it took 15 minutes. This could have been lesser, allowing me to get to the 4th and final question. Basically, imagine how you might make that problem tougher and go for it!
- Finally, do not bother with helper functions during algorithm interviews. It is always okay to say something like, “let’s assume I have implemented a heap class and it has a pop method”. You can add imaginary methods as you build the solution so long they make sense.
Patterns I practiced and Resources I used
Google search and YouTube can find you anything under the Sun! However,, here is a list of sites and channels that I found helpful along with the approach I took. The first thing is to learn how to implement and/or use some of the common algorithms, data structures and approaches with your eyes closed and one hand tied behind your back sitting in an active battlefield :), as in:
- Mergesort
- Quicksort
- Recursive traversal through graphs and trees. A big advantage of recursion over iteration is that the OS keeps track of your parent nodes rather you having to manually assign an indeterminate number of pointers to each parent.
- Depth-first and breadth-first search for linked lists, adjacency lists and adjacency graphs
- Level order traversal
- Two pointers
- Sliding window
- Heaps
- Hashsets and Hashmaps
- Dynamic Programming: build the state map, and then recursively make all possible decisions at each state and record change of state till goal state is reached. Typical DP problems have two main variations — 1) they might ask you maximum or minimum number of doing something involving one (array) or two (matrix) independent variables or 2) to find out how many ways it can be done.
- push → recurse → pop pattern in Backtracking. Frankly, my understanding of backtracking is basically, backtracking = push element + DP + pop element. And I was able to solve the N-queens problem with that approach; though my solution is still non-optimal because I have still not quite comfortable with the 10.2 technique.
You can start off with the following two lists and they are completely worth your time:
- A list of 25 algorithms: https://medium.com/techie-delight/top-25-algorithms-every-programmer-should-know-373246b4881b. The techie-delight website is also a great learning resource.
It does not cover Tarjan’s algorithm for finding strongly connected components which can tell you about articulation points and bridges in a graph. Also, I skipped quickselect. It is far more efficient to extract the K-th largest (or smallest) number by using a max heap (or min heap) of size k than using quickselect. The time complexity reduces to O(n lg k) from O(n lg n).
The next great resource is the blind 75 list. Doing these problems will give you a great understanding of common programming patterns
The other major resources that helped me:
- Leetcode (free version)
- https://algotree.org/algorithms/ (which has quite a few implementations too).
- If you want to sort problems by company without having to pay LC, look here: https://seanprashad.com/leetcode-patterns/
- William Fiset has some great videos: https://www.youtube.com/c/WilliamFiset-videos
- Graphs: https://www.youtube.com/watch?v=tWVWeAqZ0WU&t=5051s (Freecodecamp)
- Backtracking: https://www.youtube.com/watch?v=A80YzvNwqXA&t=97s (Freecodecamp)
- Recursion: https://www.youtube.com/watch?v=IJDJ0kBx2LM&t=1756s (Freecodecamp)
- Sorting Algorithms: https://www.youtube.com/watch?v=l7-f9gS8VOs (Freecodecamp)
- Dynamic Programming: https://www.youtube.com/watch?v=oBt53YbR9Kk&t (Freecodecamp)
- Binary Trees: https://www.youtube.com/watch?v=fAAZixBzIAI (Freecodecamp)
- Finally most definitely look at the NeetCode channel on YouTube: https://www.youtube.com/c/NeetCode and here are his solutions to Blind 75: https://docs.google.com/spreadsheets/d/1A2PaQKcdwO_lwxz9bAnxXnIQayCouZP6d-ENrBz_NXc/edit#gid=0
- There are also some great resources at the below links, you might find them useful.
- https://github.com/Developer-Y/Scalable-Software-Architecture
- https://github.com/Developer-Y/cs-video-courses
The InfoQ channel on YouTube is a great source of tech talks. These are more useful for the design questions.
Finally, use HackerRank and CodeSignal (“Interview Preparation” and “Arcade — Core”) to both practice your coding skills and get used to the platforms.
The Way I practiced
I think the way I practiced made a big difference for me. I had three notepads (legal pads) with me at all times I was practicing. I used one to think and solve the problems. I used a second to write down solutions to common patterns and problems I found interesting. And I used the third to write down algorithms and an example implementation for them. And I redid a particular problem or algorithm whenever I found a better solution.
Thus even if I did not have the time to practice before an interview, I could always sit down with the pads and refresh my memory quickly.
I literally did this for only a month before the Google interview — which should tell you how extremely effective this was for me!
Difficulty of the interviews
I will rate Snowflake’s online assessment as most difficult. Google is a close second, only because their first interview was not difficult. Meta comes in after that, though with some practice you should do okay on Meta. I felt the most comfortable doing Netflix’s assessment.
The difference between Meta and Google were really in their expectation from the interview. As I mentioned before, with Google I had to really think about the solution and how to code it up while with Meta I was under quite a bit of time pressure.
Benefits from this outside of interview preparation
An oft repeated saying is that algorithmic interviews are not a true indicator of future performance. And I agree with that.
There are a lot of jobs where one will never use algorithms. However, when you work at or near the edge of possibility, I don’t think that’s always true anymore. Plus the interviews also aim to test your coding proficiency, your problem solving, your ability to work with others, your ability to grasp and implement technical materials. And algorithmic interviews, in my opinion, is as much a level playing field as any other.
Personally, after 2 — 3 months of interview preparation:
- I became a much sharper programmer. (I would go as far as to say that if you want to learn a language really well, “leetcode” it.)
- I learnt a lot about a lot of algorithms and data structures.
- I am much more comfortable reading about advanced algorithms or data structures that I need for my work sometimes.
- Most importantly, I now plan out my implementations before starting to code which has made me a lot more efficient.
Conclusion
I will try to add articles to this series pointing out approaches, algorithms and lists of problems that I felt were crucial in my journey. Topics that I want to cover:
- Graphs and Trees
- Arrays
- Linked Lists
- Dynamic Programming and Backtracking