This article is about how I approached interviewing, and the information + tips contained here are simply my opinions formed through various experiences. As with all advice on the internet, take it with a grain of salt.

If there's one thing you should take away here, it's that there is no single way to get into these big tech companies. There were a lot of obstacles I faced personally that galvanized me to share. For instance, these companies have felt incredibly inaccessible to me as a CUNY Brooklyn College student, I wasn't able to do the overwhelming numbers of LeetCode problems everyone said they did/do, my nerves seem to affect my ability to perform more than others, it felt too late for me (I stopped interviewing by March), and lastly, I thought I had to know everything to get into these companies. Here are some things I wish I knew before!

Studying

I didn't 'leetcode grind'. This is the conventional advice in all of the testimonials I had read and heard in the tech community as well as the approach everyone seemed to take. It's not what I did to pass these interviews. That's not to say you shouldn't. It just didn't work for me, and it might not work for you either.

I did what I knew best; I treated it as a class. I read the books, took notes, and even memorized some things. I first studied the theoretical concepts and algorithms so that I can explain it in simple term to my younger siblings. Then, I practiced the concepts as if I had an exam coming up for it by what I might see on the exam. With almost 2 decades of exposure in the traditional education system, this felt like the most intuitive way to ace the interview.

Syllabus (sorta...)
There are three main sections to technical interviews, in my opinion:

1. Complexity analysis
2. Data structures
3. Algorithms

There's an overwhelming amount of resources to learn Complexity analysis in the context of interviewing, so I won't go into here. I will add that I am very comfortable with this and this is a must and every interview will require you to understand this.

For data structures, I studied the following:

1. Linked Lists (singly, double, & circular)
2. Arrays (fixed sizing & dynamically sized) & Strings
3. Stacks, & Queues
4. Graphs
5. Maps & Sets
6. Trees, Tries, & Heaps

This is roughly ordered from what I studied the least to what I studied the most. I studied trees and maps a lot. Graphs are important but I didn't go much further than BFS + DFS. I encountered zero linked list questions this year. Maps and sets are crucial. Arrays come up often but usually the complication is in the algorithm--not the data structure--when you get these on interviews. For strings, I just familiarized myself with the language's string library.

I studied the following for each:

1. Operations it is good at.
2. Operations it is not so good at.
3. What makes these operations slower and faster (implementation details)

I found implementation to be an incredibly strong foundation for all my interviews and algorithms. Be able to talk about these data structures and understand the tradeoffs between each one.

For Algorithms, here are the ones I recall studying:

1. All the sorting algorithms.
2. Binary Search.
3. Traversals of every data structure (trees & graphs especially).
4. Recursion & Backtracking
5. Some OOP concepts & paradigm thinking

Some I knew like the back of my hands (graph traversals) and some I still barely understand (backtracking 😅). Dynamic programming, bit manipulation, system design questions, and greedy algorithms were next on my list but I didn't get to them before the offers. I didn't need or use them, but be mindful that your syllabus varies with company, seniority, & each individual interviewer! I learned that you don't have to know everything well, but whatever you do know, you have to know it well.

I studied these using Cracking The Coding Interview by Gayle Laakmann McDowell, my university notes, Geeks for Geeks, my friend's notes from codepath, and MIT Open Courseware videos.

Although this list might seem overwhelming, you will go through some faster than others. I was comfortable with some already & some I didn't bother studying in depth. I had my list prioritized and kept revising it as I went through more interviews. The types of questions they can ask are limited, so stay hopeful!

I was also doing real interviews as I was learning. I didn't wait to master everything before interviewing. Be warned, I failed plenty of interviews and this was quite emotionally exhausting to do. If you can avoid that, please do.

Practice

Just like I would for an academic exam, I practiced for these 'exams' as well. This was two a part process for me: getting comfortable solving questions, and then practicing questions I might actually see on the interview.

I recommend you get comfortable coding and problem solving in general. Be comfortable and don't waste time on trivial matters during the interview. You don't want to waste time trying to recall how a for loop for this problem would look, or writing code and being like "oops this isn't right--gotta move these around and haha i guess i don't need this either." I did a good number of easy LeetCode questions for this. I just wanted to get comfortable solving question & it helped me build up my confidence tackling harder problems.

The Cracking the Coding Interview book has a lot of problems for each data structure and algorithm. They have multiple ways of solving problems and a great explanation to all of their solutions. You could say this was my textbook to go along with the syllabus.

After doing enough easy problems and feeling confident about the content, I did 'medium' questions on LeetCode to practice what I might see on the interviews.

Questions
Put your time into the questions. Don't just take the question at face value. Don't just do it as quick as possible. Do it once and check if it's correct. Can you do it quicker? Can you do it with constant space? Read the discussion section and see how others are solving it. Show it to your friends. Solve it in a group. Solve it by yourself under a time constraint. Explain the question to someone else--better yet--mock interview them! Revisit it weeks afterwards and see how you approach it differently.

Sometimes you get stuck and can't think of a solution. Solve it simply. When you have a way to solve it, just solve it. Brute force it, if you must. Even if it's the ugliest and slowest way to solve it, it's a start.

Though I had a good balance of breadth & depth of questions, I think I valued depth more than breadth. I couldn't do a huge number of questions. They say you're supposed to give 15 mins to a question that has you stumped. I would spend hours, days, or even weeks on the questions. I would ask my friends, email my professors, read and watch everything until I understood it intuitively. Everyone told me it was unproductive to be stuck on questions in that manner. I really tried changing, but for the most part, I couldn't and it was frustrating! It was hard to leave a problem unsolved and I thought I was doing preparing for interviews incorrectly. I am not advising that you spend hours on each question, but I am sharing that I did. I didn't follow the mainstream advice (despite wanting to) and it worked out fine for me.

Real Interviews
Solving interview questions on your own isn't the same as they would do in interviews. I used pramp.com to get better at communicating during the interview and challenging myself to do it under the pressure of real interviews. Pramp allows you to schedule a mock interview with other people for free. There is a limit to how many sessions you may schedule but they increase it if you are rated well after the interview. It's a really good tool and I highly recommend it. I also did mock interviews with my friends and the other communities I'm a part of (CUNY Tech Prep, FB Above and Beyond CS, and the Computer Science Club at Brooklyn College).

The Interviews

"I don't expect you to be a human compiler" - my Facebook interviewer.

The interviewer, recruiter, and the company wants to hire you. Beyond your technical skills, the interviewer is assessing whether or not they want to work with you full time. This is the reason that communication skills matter.

It's not optional or a nice to have, it's a make it or break it, just like your technical skills are. I can't stress this enough. Don't overlook this.

Small Talk
The interviewer might be on their fourth interview of the week, they might've had a code release that was rough yesterday, they might personally be having a bad day, so do them a favor, and make this 45 mins as pleasant as possible. Don't just go straight to business, don't try to take lead of the interview, try not to be so nervous, and remain polite, pleasant, and attentive throughout the scheduled time.

The first thing I always do is thank them for their time. I tell them that I'm grateful for the opportunity and really excited for this interview. My introduction is equally detailed as theirs is and I follow whatever tone they set for the interview.

If you're not comfortable with this conversational aspect, I recommend that you take some time to write down your intro, some pleasantries, thank you's, questions to ask after the interview, and common phrases before the scheduled interview. I don't recommend you try to read them during the interview, especially for an in-person one but I recommend you write them down so that they're fresh on your mind and hard to forget in the moment of nerves.

A little social anxiety is nothing to be ashamed of and I'm with you on this. I imagine you'd only have to do this about 3 times or so to get comfortable and not rely on writing these things down before interviews.

First step

You're solving the problem with your interviewer, not in front of your interviewer as they watch and judge you (usually 😅).

When they give you a problem, make sure you understand it. State your assumptions, ask about edge cases, run through the needs of the problem, and look out for any keywords. If you don't know where to start at all, running through an example might help.

Sometimes examples don't help and you're just stuck. You share that painful silence with the interviewer and wish the 45 mins would run out quicker. It's probably because you've never seen an interview question like that before. Sometimes, you just don't know things. Do as many questions as you can so nothing catches you off-guard.

I always explain the steps my code will take to solve this problem just to hear their thoughts on it before I start coding. This is where they usually give the most helpful feedback.

Feedback
As soon as you get the question, you're already doing an exchange with them.

• "This seems like a DFS problem..."
• "I might need a hashmap for this..."
• "This algorithm would be much faster if it was sorted..."

See what their feedback is. Are they hinting you to go towards one solution over another? Are they suggesting some edgecase with this example? Their feedback is incredibly valuable, so be attentive. Them guiding you and questioning your approach is normal. You didn't do anything wrong and they're trying to be helpful.

It's okay to make mistakes on the interview. Your first approach doesn't have to be the right one. It's all about how you bounce back from it. Think of the interview as a code pairing session. Responding to feedback, positively, is a huge marker of your skills, confidence, and agreeableness.

Positively also means not beating yourself up over it and quickly implementing it. You can hit 'em with the quick "ah! ofc, that makes sense since a hashmap is great at lookup. thank you, good catch!"

Remember that your interviewers aren't human compilers either. They're people. So connect with them, make them laugh if you can, show them you're listening, and thank them for their time. Bonus points if you can find something in common and form a more of a personal connection!

Pep Talk for the Nerves

The hardest thing for me during the interview process was the nerves. I don't know if I'm alone in this, but I can't think as I usually do when I'm nervous. Furthermore, I can barely communicate when my nerves get to me. I feel physical discomforts from the anxiety too! If I can do it, so can you. 😁 My interview anxiety weakened as I did more practice problems and gained confidence. I memorized some algorithms by literally using some physical flash cards. I've never done that before for coding but I remember my friend did it for our algorithm's class, so I decided to try it and it really helped. The incentive was to get it to become muscle memory and this saved me a lot of time during the interviews.

Accepting that I might not get it (and that's okay) also helped a lot. Truth is, there is an abundance of opportunities for employment. Everyone is looking for enthusiastic, intellectual, and persistent engineers. It's okay if you mess up this one--there's another one, and one after that, and so on. You're going to be okay! It's only failing if you stop trying. Even if you studied & interviewed for 16 months, it doesn't matter when you end up at <insert dream company here>. Just stick with it until you get there.

You got this.

You don't have to be perfect. You don't have to know all of it. It's also okay if you forget it. I'm very comfortable with complexity analysis and my data structures but I have some room to improve on algorithms. I stopped interviewing and studying for about 2 months and I already forgot a lot. It's okay! That's why we keep notes. I have about 3 private google docs, and a public repository. (and now this article 🎉)

The technical interviews are tough and can take a toll on you. I urge you to take care of your mental and physical health during the process. Make sure you are eating, sleeping, getting exercise, and socializing at a healthy amount. This balance will help you do better on interviews and allow you to keep interviewing for longer. It's a long term game and you can't let yourself burn out.

I studied a lot and it was exhausting. It's hard to keep up the momentum consistently. Somedays I had to force myself to study, somedays it was easy to study because I had an interview I was excited for, and somedays I couldn't force myself to study by any means. The flux is normal! Take interviews often. Even if you don't get in, it's good practice. And don't be too hard on yourself.

Though I don't believe the interview process is perfect, I do believe they make us better programmers. Even if the content is irrelevant, they still measure other key factors. They measure how persistent you are, your ability to learn, your ability to study, your willingness to rise to the challenge, your ability to take feedback middle of coding, and your ability to communicate under pressure! I think these are essential and valuable metrics that the interviews I've personally been on have captured.

From me, the problem was that my academic studies, internships, projects, and interview preparations all seemed too independent. I felt there wasn't enough overlap between these and found myself annoyed that all these things I'm doing barely helped during the interview process. On top of everything, taking time for studying interviews was a challenge for me.

Personally..

Resources that helped me

1. Facebook Above and Beyond CS - a 12 week course taught by Facebook engineers. It didn't give me any special consideration for the interviews but the content was great. I have a habit of being stuck on questions and their syllabus kept me moving. The cohort met every week and two questions were due. I always aimed to do all of the questions before class, often sat in front, and participated as much as I could without being overbearing. There are similar courses available. CodePath sounds amazing! I applied but didn't get in. I believe some schools have their own separate course for interviews.
2. LinkedIn - A lot of people overlook LinkedIn but this is what got me connections from Amazon & Apple. It's the only reason I was even considered for the positions. Amazon reached out to me, and I reached out to Apple. I got on a call with both managers and they encouraged me to apply. A lot of recruiters are on LinkedIn scouting talent, so make sure your profile is polished!
3. Rewriting the Code - is a fellowship that has grown a lot the past few years. A kind stranger in the fellowship referred me to facebook. This is what got me my Facebook interview. The community of women at RTC are smart, kind, and supportive! RTC also hosts a summer mentorship program that introduced me to my current mentor, Omar. These two have been a huge game-changer for me.
4. CUNY Tech Prep - CTP provided monthly mock interviews that I took full advantage of as well as any last minute student cancelations I could fill in for. The students were also applying and actively interviewing so it was easy to stay focused and motivated with them. I also made some friends who were 10x smarter then me & they motivated me a lot!
5. Pramp - It schedules mock interviews with other students who also need practice. They give you a question and the solution to study so you may interview your counterpart at your scheduled time with a language of your choice.
6. Cracking the Coding Interview - This is the holy literature of interviews. As mentioned earlier, this is my "textbook" for the "class". It's kinda legendary, so I wont bother to expand on this. I basically read the chapter, tried the questions, learned complexity analysis, and studied how the different ways the book solved problems. I didn't code out all of the questions I went through. I only coded the ones that stumped me. I also read the chapters outside of the technical chapters.
7. LeetCode - It's a website where students can practice interview questions and see what companies tend to ask. They also have discussions and posts by other interviewees that I found very helpful.
8. Community - My friends, mentors, and the CS club were really important to me during this process! They kept me healthy and encouraged me to keep trying. This is a long term game, so keep your mental and physical health in top shape. My immediate community reminded me of this often. We also share our resources, methodologies, and help prepare one another during the process.
9. Back to Back SWE - This is the only interview channel that I found helpful when I was stuck. There are a lot of channels who solve problems but it feels like they looked at the solution and coded it in front of the camera. Back to Back SWE does a phenomenal job teaching the material and clearly understand it intuitively. I watched his backtracking video a ridiculous number of times.

That One Month

I will add that though I've been interviewing on and off since my first year (I'm on my fourth year right now), I think I did at least 74% of my interviews this year. I did especially a lot during winter break (month of January) and that is what really got me these offers. I cancelled all my plans and almost everyday I was studying interviews.

That one month of studying is what really carried me. During the Fall semester, I was working, was learning the PERN stack at CTP, held at least 3 events a month for the Brooklyn College CIS community, was at a maximum number of credits allowed, travelled a lot, and also had weekly classes from FB ABCS. Though my university classes and FB ABCS built the foundation for my skills, my interviewing skills were actually developed in the month of January. I was not working, school was off, and I didn't have to leave my house much so I focused on interviewing a lot more intensely. I didn't know if it would work or if I could get any offers. I just knew that I've been postponing these interviews forever and need to get it done soon.

You might need to push for one more month too. For whatever companies you're aiming for, I hope you get it. If there's one thing you should get from my story, it's that there is no one way to get to the big tech companies. Your interview process and experience might be different, that is okay and you can still make it. There's enough room for all of us in there. I'll see you there!

Thanks for your time, cheers!

Shahzoda