Status: 4.5 years experience at company local to me.
Position: E4 Software Engineer at Meta
Location: Remote (US)
Date Interviewed: December, 2021

Since I signed an NDA I will not go into the specific question but give a general sentiment of difficulty and how the problem went. While a lot of the questions are similar to leetcode they are not word for word copied from leetcode so do your best to study ideas and not memorize solutions. I also want to point out that I had a ton of rejections leading up to this and if you are interested in learning about my journey check out Coding Decoded on YouTube (can't post links). There is also a link to the resources that I used to study in the video and things that I thought were helpful.

---

Notes on strategy to solve coding problems in interviews

• In all cases for data structure and algorithms questions I followed basically a 6 step strategy. I outline that below as a template I used when going through these questions in my interviews.

  1. Ask clarifying questions to understand the problem completely. If there is still not enough clarity, work with the interviewer. You can't solve a problem if you don't understand the question that you are being asked to solve. Don't under-estimate this step and don't make assumptions. If you go down the wrong path you will waste your time and it will be extremely difficult to make up.

  2. Propose a solution by walking through it on the coder pad. Visually write out how the algorithm would perform with a small test cast so when it is time to code, the problem is already solved, and you just need to regurgitate it in the language of choice. At this step I would also mention time and space complexity and explain why this is probably the best we could do in terms of overall performance. This allows the interviewer to interject before you start coding if they think you can do better.

  3. Write the code for the problem. Sort of funny, but this is actually probably the least important part. Obviously write good, clean code (and know useful libraries in the language you are coding in) but at this point it should be secondary because you've already solved the problem.

  4. Walk through the code with some test cases and find any bugs / logic errocs that might be present.

  5. Talk about different edge cases that could cause the algorithm to fail. You won't always have to address the edge cases in the code since it might drastically change the way the algorithm is built (I.E. using longs instead of ints in java) but the interviewers want to see that you are thinking about this and will mostly just ask what edge cases do you think could come up.

  6. Confirm the runtime and space complexities. At this point the interviewer should basically say, "Yup looks good." Or interject somehow.

---

Technical Phone Interview

• Question 1

  • ~Leetcode medium. Most of the time interviewers will start with a "warm up" problem so I assumed that is what I was getting here. The problem seemed trivial (if you could verify greedy component of it) but after finding similar questions on leetcode it fits roughly in the medium category. Overall went well and talked about a solution with interviewer and he seemed pleased and finished coding it up in ~15 minutes.

• Question 2

  • ~Leetcode medium. This problem was a little more involved so I did my best to walk through the test case carefully and understand exactly what the solution might entail. Recognized the pattern and was able to walk through a solution and put it into code.
    

• Thoughts

  • Overall, I thought things went well and assumed I would be called for an onsite but it can be hard to gauge, so I was definitely not 100% certain I would move to the next round. I ended up getting a message from my recruiter about a week later letting me know that I moved to onsites.

---

Onsite Interview

This interview was originally scheduled for a single day but, because of interview availability, some things had to be moved around. In the end, it consised of 4 rounds split into 3 days.

• Day 1

  • Behavioral (1 round)

    • Really not much to go into here since behavioral is very subjective. One thing that I found to be really helpful though was to write down a timeline of all important events that had taken place in my personal and professional life. When an interviewer asked a question I could quickly consult my "cheat sheet" and help choose from a bank of experiences. We really only talked about 1-2 problems and the individual dove deep into the technical aspects of it. Make sure you aren't lieing about experiences because interviewers are trained to spot this and they will dive very deep into technical aspects to see what challenges came up and how you overcame them (among other things). I was genuine and felt like we had a good conversation but always tough to tell how well you do in these.
      

• Day 2 - Data Structures & Algorithms (2 rounds)

  • Round1 of DS & A (3 questions)

    • Question 1

      • ~Leetcode easy. Quick warmup (pretty trivial) and then we jumped into the second part which sort of compounded on ideas from this question (although completely new code).

    • Question 2

      • ~Leetcode medium. Differen't question than the one above but similar idea. I was able to come up with a solution quickly. The interview mentioned that there would be another question so quickly walked through test cases and what not before moving on.

    • Question 3

      • ~Leetcode medium. This question was not similar to the previous two at all. I had solved similar problems so I was able to identify possible solutions quickly and come up with a solution. Solved with a few minutes to spare and asked the interviewer some questions.
        

  • Round 2 of DS & A (2 questions)

    • Question 1

      • ~Leetcode medium. Identified the best way to solve this quickly by working through test cases and was able to code up and walk through the problem in about 20-25 minutes.

    • Question 2

      • ~Leetcode medium. This problem was easy to identify but had a few tricks in the problem that caused me to pause and explain why I was having trouble finding a solution. This was a little "clunkier" than my other questions but I was able to come up with a working solution. Interviewer iterated on it and asked if I was able to come up with a better space complexity. I Identified parts that I thought could be improved and proposed an answer without putting much in the code. Not perfect but I still felt like it went well.

• Day 3

  • Systems Design (1 Round)

    • At Meta you can choose either Product Design or Systems Design. I honestly don't know the main difference between the two but if I had to guess, the System's Design tends to lend itself to build an entire system and dig deep into parts such as data partitioning and how to build other relevant services in a largely scalable system. From my understanding product design is more focused on API Design and building entities. In product you will still have to have a good knowledge of how a system is built but the interviewer may focus less on overall high level design and data partitioning and more on the previously mentioned things. Also, I don't represent Meta so take this with a grain of salt and if you have interviews coming up, check with your interviewer on expectations.

      Moving into the interview.... I wasn't sure what to expect from this and tried to follow the general systems design guidelines. The interviewer drove me in a direction and it is important to take feedback and listen to what the interviewere wants to cover. In this round I focused on trade-offs. If I was asked a question I tried my best to give the top 2 or 3 answers and ultimately choose 1 and gave reasons why I thought this was the best. I felt like the discussion was good but was hard to judge since I didn't follow the exact steps I had studied for on a normal systems design interview.

      
      

• Thoughts on Onsite

  • I thought that overall things went really well but I had dealt with so many rejections in the past and I didn't want to get my hopes up just to get another rejection call/email. My final interview was on a Friday afternoon and I heard back from my recruiter via email later Monday afternoon. While they didn't say I was going to get an offer they hinted that my scores were strong. The recruiter and I set-up a meeting for later that day and he confirmed I was going to get an offer but didn't go into compensation because it had to be cleared by the comp team. Obviously ecstatic at this point and finally felt like all my hard work paid off.
    

---

Negotiation Tips

There is a lot of great resources out there and I would defer to Haseeb Qureshi's negotiation tips (type into google because I can't post links) when negotiating as he is much smarter and better at it than I am. I did write a few useful tactics down that you can use when negotiating.

• The best way to negotiate is to have a counter offer in hand, but for a lot of people, that may not be a reality.

  • I was lucky enough to get another offer from Microsoft so I had some leverage in this category but, to be honest, the recruiter never asked for compensation details regarding that. Obviously be transparent with your recruiter and when an offer comes in, let them know because this will be your strongest negotiation tactic.

• Something else you can do is leverage your current position.

  • If your current job pays X but you want to make Y. Be transparent with the recruiter that you are very excited with the offer but there is uncertainty when leaving your current job and if they can hit target Y, you will sign.

  • Having a job is a negotiation tactic whether people think so or not. There is always an opportunity cost when moving from one position/company to another. If you are coming from a smaller company like I was, this may not work the best, but if you are coming from another competitor it could be beneficial.

• One thing I did, that I thought was very helpful (I would only do this if you are going to go through with it), was to tell the recruiter how excited I am to get an offer and that they are my main choice. In this case, the company was my top choice, and I let them know that I would be willing to stop interviewing (I had interviews still ongoing with other FAANG companies) if they were able to hit specific numbers.

  • Obviously dont make random numbers out of the blue. Do research on levels.fyi and check out people who got offers on teamblind. Find out where the band falls for your given level and position and let your recruiter know you're not making these numbers out of thin air. If you tell them you did research and you know that they can hit these numbers they should appreciate the effort you put in.
    

---

Closing Thoughts

• For one, if you made it this far, I am impressed. Sorry for rambling but I wanted to give as detailed of an explanation as I could into the process.
• Next I am going to get into some uplifting words that I hope can make an impact on people dealing with interviews. If that isn't your style, I would stop here (I added a bunch of line breaks so exit now).
  

- ## **INTERVIEWING IS REALLY HARD. DON'T BEAT YOURSELF UP OVER A REJECTION OR CONSIDER YOURSELF A FAILURE** - I can't tell you how many times I was rejected or felt like I wasn't good enough for a company or position. This could never be further from the truth. I couldn't be more of an average person who had a vision on what sort of company I wanted to work for and stuck to the plan. **If I can do it, I PROMISE, YOU CAN TOO**

• Focus on what you can control

  • It is really hard but you will never feel prepared before an interview (at least I never did). There is always another question that might be asked, and always a new topic that can be discovered to get better at data structures and algorithms. Realize that there is no "perfection", but strive to reach it, and go into every interview with an open mind.

  • There is also a million reasons why you may not have been selected for a position that are outside of your control. Maybe a company is just fulfilling interviewing number obligations and they dont plan on hiring anyone. Maybe another candidate is a genius and obliterated their interviews. Maybe the interviewer is having a bad day or doesn't like the t-shirt you are wearing so gives you a bad grade. My point is, often times it isn't you and interviewing can be a numbers game. If you didn't get the offer, screw that company and move on. Focus on enjoying the experience and getting better and don't focus on bad questions or not passing the interview.

• Be your biggest critic.

  • Regardless of how well you do in an interview you will never be completely flawless. Be mindful and proud of the things you did well but take a hard look in the mirror and try and find any spots for improvement. In almost every single one of my interviews (regardless of outcome) I can tell you something that I didn't do perfectly. Constantly improving is the name of the game and the best way to do so is to be extremely critical of your performance and find spots to improve, even if they are small.

• It takes a ton of determination and bravery to do these interviews.

  • The definition of bravery is: The quality or state of having or showing mental or moral strength to face danger, fear, or difficulty.

    • I can't think of a better word to describe the mental fortitude it takes to go through this process. Yes, it is just an interview, but everyone wants to be successful and move to the next round. I don't know what the pass rate is for most large tech companies, but I know it is very low (especially at onsite stage). Failure is almost a statistical guarantee and it takes courage to charge ahead in the face of that uncertainty. You are a winner for attempting the process and you should be proud of that, regardless of the outcome.

• Luck plays a large role in the process

  • There are so many factors outside of your control and it takes everything to align just perfect for an offer to be reached. The biggest advice I can give here is realize this and embrace it. The more problems you solve and the better your knowledge grows, the less luck will play a part, but there will always be a solid amount of randomness involved with interviewing. Try to learn from every interview and approach each one as a new chance to get better and learn something, but realize the cards have to fall just right to be successful in this process.

Best of luck everyone in the Leetcode community and please reach out with any questions you may have.