After my last organization (Creator Now) was successfully acquired, I started my journey to join a big tech organization. My ideal goal was one of the FANGs (or MAANG — Meta, Apple, Amazon, Netflix, Google).
This is the story (and knowledge sharing) of how I was able to land 4 Staff/L6 Software Engineering offers in different organizations (Amazon, Meta*, Stripe, and Braze).
Disclaimer: Meta requested me to do an extra final interview after going through all the rounds. As I had already decided to go to Stripe, I decided to pause the process and not go the extra mile. I am pretty sure they wanted to see if the leveling was right (L5 vs L6), as they commonly do it when you do not ace all the interviews.
I failed a lot, so I could succeed You might see the title of this article and think “this guy is probably way out of the curve” or “I can never get those high-level wins”. The reality is: 1. I actually put a lot of work and hours in making this happen; and 2. I had some pretty bad moments when riding this path, which made me think I was not gonna make it.
I want to highlight all the worst moments of my journey, and some of the negatives I got. This might shine some light into your path and maybe it will make you think that shits happens and this is hard, but doable. All you can do is keep moving forward, and you will eventually get there.
I failed my very first phone screening interview. And this was with a company that I thought had a pretty low bar for SWE. That destroyed my confidence for the next few days. When doing a mock coding interview with a peer, I got a bad brain freeze during an easy question. I literally could not do a simple task that anyone that has a decent SWE domain knowledge would ace. And this was when a friend of mine was trying to help me — I felt a lot of shame, and I was hopeless after the session. Google did not even accept my resume. And Google was probably my #1 company at the time. Not only that, I had a referral. Getting a rejection out of the door, without even having the chance do try was pretty bad for my ego. Was I not good enough to event try? I got rejected by a small company after a technical screening round. Sure, my target was big tech companies, but I did apply to some small organizations to get my interview skills warmed up. This was yet another low for me, since my understanding is that their technical bar was not nearly as high as Google, Meta or Amazon. I could not resolve hard LeetCode questions and I still struggled on them after a few weeks. Even on the week before my interviews, I am confident in saying I could only actually solve 40–50% of them. Spoiler alert: most interviews will not ask you such hard/niche questions. I cried of frustration. It sucked, and I had to pick up the pieces along the way to keep going. But, hey, this is all in the past now. And I want to share my major learnings, so I can maybe expedite this process a little bit for you. Let’s dive right into it.
Iam going to assume you are familiar with how the big techs interviews work — and that you most likely have read the common-sense knowledge out there on how to succeed (if not, check my first recommendation on the “Helpful Resources” section).
Therefore, I will focus on things I wish someone else had told me before/during my journey and also the best advices I have received. Finally, I will share some great resources that have helped me along the way.
Key Takeaways Interviewing is a skill and it does not reflect how good you are as a software engineer. As with any other skill, you need to learn how to master it, apply it in a simulated environment, and reflect on feedback as much as possible. You will suck at the beginning. You will fail. The important thing to remind yourself is that this is not a testament to your abilities as an engineer, but rather on playing this weird game. Your job is to convince whoever is interviewing you that you can do the job. It is not necessarily reaching the optimal solution. It is also not about landing a system design that would work in real life. Yes, those are great things to do, but those are means to an end. At the end of the day the interviewer is the proxy of how good/bad you have done, no matter if you actually did well or not. Use the time you have to flex your abilities. This is your show — make sure you not only reach to the destination, but flex your way through. This also takes me to my next point… Each interview is an encapsulated experience. And shit happens. You could have a bad day. The interviewer could have had a bad fight with their partner the night before and is in a bad mood. You could get that one question that you cannot solve because of reasons. Do not let the outcome of one interview affect you for the other (either for the good or bad). What you have to trust is the process. Are you putting in the hours? Are you progressing on LeetCode, etc? If yes, then that is all you need. Do as many interviews as possible, starting from the lowest priority ones. You should apply to companies you are not necessarily excited to work for. Not only to get real-life experience but also because competing offers are the best weapon at hand when you want to negotiate your salary down the road. This means that you should also… Try to align your top-tier companies’ timelines as closely as possible. Remember, this is your main leverage when optimizing your compensation package. Also, there is nothing worse than getting an offer from company X and still not knowing how Y and Z will pan out. However, make sure you leave at least one or two days in between each interview. This will ensure you have some time to rest & recover between each step. Do not let other people experience affect your view of your own process. Each one of us has our own interpretation of the reality and the process. I found myself often times feeling overwhelmed because John Doe shared that he got two Hard questions on his 1h interview. Well, how hard is hard for John Doe? What are his expectations and how well does that translate to your reality? The truth is: trying to apply anyone else’s reality to your is rarely going to give you any meaningful insights. Do your thing. Focus on yourself. Pay for mock interviews. I cannot emphasize enough how much I got more confident over the real thing after I paid a couple of mock sessions (see more on “Helpful Resources” section). The strategy I used was doing a session every Thursday or Friday. This way I could get a sense on how much I was improving each week. It is the only thing that actually mirrors the experience 1:1, which can be decisive for you to feel more calm and relaxed when the real deal comes. Helpful resources Tech Interview Handbook: Must read. Goes through all the steps for getting a job at one of those giants. Especially helpful if this is the first time you are doing this process. LeetCode: Must have. The premium subscription helps cut off a lot of time for understanding the best solutions via the editorials. If you can spare a few bucks, totally worth it. Grind 75: It is important to optimize your time by selecting the most relevant LeetCode questions to spend your time on. This is exactly what this tool provides: you share how much time you have on hand and it will craft a roadmap of questions for you. LeetCode top company questions: After grinding through Grind 75, I switched to doing all the top 100 questions from whatever company I was interviewing for. Some of the questions on that list were surprisingly close to the ones I was asked in my interviews. Interviewing.io or Hello Interview: Mock interviews. These are paid, but I cannot stress enough how important it was for me to simulate the real interview scenario. I would have a way harder time if it was not for me paying a couple of mock interviews. Jordan has no life: Besides the funny name, this YouTube channel is hands down the best resource I ever found online for system design interviews. Most channels are too shallow on this sort of content. Jordan does a phenomenal job going to the next level. This specific video on Dynamic Programming: If you are struggling to understand how to understand and apply dynamic programming to your coding questions, this is the only video you likely need to watch. Algorithm cheat sheet: I created this because I wanted something to quickly review the most common patterns and problems 1–2 hours before an interview. It helped me refresh my brain without being too overwhelming. Therapy: I have been on anxiety medications for the last couple of years, and along with therapy I have been able to create mechanisms and strategies to cope with my anxiety peeks. I do not think I would be successful without seeking professional help for my mind as well. Not-so-helpful resources LeetCode Subreddit: Do not get me wrong, I love Reddit (and this subreddit too). However, I often found myself reading through posts about people complaining about how hard this process is, or the unlucky ones that got hard questions on their interviews. It was not great for my mental health, and neither provided me with any relevant information. This is my experience. I know it has great uplifting posts as well, but my brain was always dragged to the negative ones. LeetCode forums: People share their interview experiences on LeetCode, and it might seem a great idea to go through them. However, they did not provide a lot of insight and often just made me feel scared/overwhelmed about the entire process, especially because I realized people tend to share their negative experiences, which might give you the wrong perspective that most people will have such experiences. I hope this was helpful at some level. If you have any questions, feel free to add a comment or reach out via LinkedIn.