Meta E4 | onsite | Reject

My interview journey for an E4 position at Meta began with a phone screen. The first question was implementing an LRU Cache. I was familiar with this problem and successfully solved it using an optimal solution involving a doubly linked list and a hashmap. The interviewer, noting the complexity, deemed one question sufficient. However, I was then asked a conceptual question very similar to LeetCode's Daily Temperatures, which I explained without needing to code. This round went well, and I proceeded to the onsite interviews.

The onsite portion had two coding rounds. In Coding Round 1, the first question was quite straightforward: given a window size, calculate the moving average within that window. For example, with [1,2,3,4,5,6,7] and k = 3, the output should be [2, 3, 4, 5, 6]. This was a direct solution. The second question was the classic graph problem, Word Ladder. I knew this one well and coded the solution smoothly.

Coding Round 2 also consisted of two problems. The first was similar to 'Valid Word Abbreviation', which I found very simple and completed the code and walkthrough in about 5 minutes. The second was akin to 'Binary Tree Right Side View', also simple, and I managed the code and walkthrough very quickly.

The Behavioral round was arguably my best. The interviewer was incredibly kind and friendly. We discussed some of my complex projects and how I approached solving the challenges within them.

My struggle came during the System Design round. Despite extensive preparation from sources like Alex Xu (Volumes 1 and 2) and 'Grokking the System Design' (which I completed entirely), along with various videos, I received a mobile system design question rather than a typical backend one. The problem was to design a library that, given a URL, downloads files from external sources. The interviewer even provided a function signature: func($url, ?= parameters). As I asked clarifying questions, it became apparent he wanted me to focus on the client-side, seemingly assessing my JavaScript proficiency, particularly concerning promises and threads. I continued to answer based on what I thought would be a good design for such a library, addressing questions about thread management and safe numbers. After the interview, I researched and found the problem was indeed similar to a Mobile system design file downloader library, as discussed in a blog by ProAndroidDev.

I was genuinely disappointed, as I had dedicated my preparation to backend system design, and the rejection felt largely based on this unfamiliar area. It made me realize that even if you're not expecting it, preparing for mobile system design is crucial, and refreshing JavaScript concepts can be beneficial. Wishing everyone the best of luck in their interviews!