How I got a FAANG offer without grinding Leetcode

I basically haven’t touched Leetcode since December 2019. From that time until now, I received both internship and new grad offers from a few FAANG firms and unicorns.

By this, I don’t mean that I’m good enough to pass without practice. I’m decent at coding and have good extracirricular experience, but I’m just not great at Leetcoding. Even when I was actively trying, my stats were pretty embarrassing. I knew the common advice was to keep pushing until the pattern of the problems became intuitive, but I found that doing so was decreasing my passion for my field. Honestly, I just didn’t want to do it, so I didn’t.

If, in the future, I see more value in practicing Leetcode for my career goals, I would absolutely do it. I just don’t believe in the mentality that Leetcode is the be-all-end-all of recruiting.

Here is my experience.

1. Rationale

I’ve always wanted to work on infra. The classes I did strongest in all had to deal with OS and architecture, and my lab/project experiences were oriented as such. I was more comfortable with giving Leetcode because I knew this niche placed less emphasis on this kind of programming.

I spent my time making sure that everything else in the recruiting process went well instead. Essentially, I wanted to make sure that the point of failure for interviews was that I didn’t know how to approach a problem. Depending on the skill gap between myself and the problem, this may or may not be remedied by more Leetcode. Maybe a a few hundred Leetcode questions could have landed me a few more offers. But I also think that university SWE recruiting is a crapshoot, and I was willing to take my chances and fully commit to my belief. My mentality was: I only need one yes.

2. Figuring out my game plan: before the interview

2.1 Being honest about my technical skills

In general, the university recruiting pipeline looks like this:

1. Online assessment
2. Phone screen, and optionally a second round in the same format
3. Onsite

The first two bullet points for non-quantitative firms are mostly the same. The point of divergence is in the onsite: some companies don’t ask Leetcode-style questions here at all.

I knew that both OAs and phone screens mostly test general coding competency and a bit of data structure knowledge, which meant they were likely to be Leetcode easy or ‘design a class’-type problems. The no-Leetcode approach assumes that these rounds can be passed without practice, and I was confident in this. Nonetheless, I made sure I reviewed basic operations and time complexities of different data structures.

In the 2021 new grad recruiting season, I had a 90+% chance of advancing past an OA if given one, and an 80+% chance of advancing past a phone screen.

2.2 Choosing and Prioritizing Firms

I researched companies that did not place a heavy emphasis on Leetcode in their onsite rounds. Out of those, there were only a handful I was interested in, so I prioritized those companies. I subscribed to mailing lists and connected with recruiters at these companies on LinkedIn (they’re really friendly!) so I would know as soon as applications were live and apply ASAP. That way, I could start the process early with them so I could schedule and plan around my whole recruiting season around these companies. In the 2021 recruiting season, I was able to get to the onsite stage for every target company.

At the same time, I went to (virtual) career fairs and dropped off my resume as much as I could. As the season progressed, some recruiters reached out to schedule interviews for specific teams in their companies that were interested in me based on these experiences; these pipelines were team-dependent, and unlikely to be Leetcode-based. I prioritized these interviews as well. I received an offer from one FAANG firm this way.

3. Doing my due diligence

There were a number of other things I did to make sure I maximized my chances.

3.1 Systems & design interviews

Non-Leetcode does not equal easy interviews, and require preparation. Fun fact: I failed a systems onsite interview with NASA in 2019 due to insufficient prep. It was my dream internship; I made sure to never take a systems interviews lightly again.

3.1.1 Operating systems knowledge

Before my interview for an infra-oriented role at a FAANG, I found a copy of Operating Systems: Three Easy Pieces and my notes from my OS class, cleared my schedule, and spent about 2 days revising every topic the official interview website told me to prepare for. I found mini case-study questions (e.g. “how would you go about diagnosing what’s wrong if you’re unable to ping a website?”) and tried to answer them myself, down to what Linux commands I should use. I got an offer.

3.1.2 Systems Design

I think my prep for this was quite light. I found some suggested structures of systems design interviews and followed case studies of how to approach the problem. I then skimmed some sections of Grokking the System Design Interview, though I didn’t look through it too hard because I knew this book was geared towards experienced hires.

Overall, I passed at least 2 of the 3 systems design interviews. (I was unable to gather feedback for the last one, though I failed that onsite as a whole.)

3.2 Explaining technical details

I think the most overlooked component of interviews is code explanation. For easier problems that many candidates can solve, the distinction between individuals is in their ability to communicate what they’re doing effectively. This comes through in two ways: ability to explain code, and ability to explain technical concepts.

3.2.1 Explaining code

I found that the most useful way to practice explaining code is to tutor underclassmen. I was very fortunate to be able to do tutoring through UPE, which built a strong foundation for my communication abilities.

3.2.2 Explaining technical concepts

This involves explaining higher-level details about something technical. For example, how would I explain what an asynchronous request is to my mom? (This problem is particularly pertinent because I was on an Async team for my internship.) I prepared for this by asking PMs about how they would explain the team/project I worked on to their family and friends. This formed a framework for how I structured my explanation, and I could add and subtract details depending on my audience. My physical therapists were also unfortunately subject to listening to me talk about concepts I learned at school that I was excited about. If they could understand at least some of it, it was a good sign.

3.3 Behaviorals

3.3.1 Behavioral questions

While I don’t think it’s necessary to have word-for-word responses prepared for every possible behavioral question under the sun, I think it’s important to reflect on my past experiences so I can have a candid discussion of them in my interview so that I can most accurately present my ability to work with others. Here are some notes I made to myself to this end:

• Consider the STAR method: situation, task, action, resolution. Some companies actively encourage you to respond in this format.
• You are in control of how you interpret a prompt. Terms such as‘failure’ is subjective, so you can explain your viewpoint of what they mean to you.
• I think it’s important to be honest about your experiences and the lessons you learned, because some behaviorals are conducted by people you’ll be working with, and you want to make sure they actually think you’ll work well with them!

3.3.3 “Why do you want to work for our company?”

I made sure I had above-surface-level reasons for interviewing. This took a bit of time, but it also helped me narrow down what firms I really wanted to work for.

3.4 Referrals

I had friends working in some of the firms I was really interested in, and they were happy to refer me. (I have great friends!) I knew that a real person was going to read my resume, so I made sure to read the job description to figure out what kind of keywords I might want to highlight. For firms that asked for a short blurb for referral, I wrote something that emphasized how my experience was useful for the specific role I wanted.

3.5 Recruiters

I actually really enjoy building a relationship with my recruiters regardless of whether I get/take the job or not. I think being open and communicative with them is the best policy. Advocate for yourself nicely! It never hurts. Here are some things I’ve gotten just by communicating:

• skipped additional phone screens;
• got additional breaks during onsites;
• negotiated for the highest possible hourly rate for an internship at that particular company.

The most important piece is being timely with communication so recruiters get lead time to adjust. Basically, as soon as I had updates, I reached out.

Conclusion: Opportunity Cost

I think my method worked really well for me. Not Leetcoding for me did not equal not working to ensure I did well in interviews at all. I just didn’t think I had enough time to do school, do all this other interview prep, maintain my overall wellbeing (socializing plus exercising 4+ days a week) and do Leetcode on top of all that. Something had to give, and I chose Leetcode because I think it had the least time-to-value ratio. My view is that, in short, the time I invested in doing these things paid off more than spending it being unhappy and doing Leetcode. Ultimately, I think each individual’s recruiting strategy should be based on the opportunity cost of doing one thing instead of another.