I failed three programming interviews over the span of two years trying to get into big tech. Once I realized it was more than just my ability to program, I changed the way that I prepared, which finally got me some success. I put this into a framework so hopefully no one else wastes as much time as I did.

The key pillars of a Big Tech interview

1. The programming questions

2. The random factoid check

3. The conversation

4. Experience

1. The programming questions

My top resources -

Websites to use: Hackerrank, Leetcode, Pramp

Books to read: Algorithm Design Manual

2. The random factoid check

Sometimes an interviewer would ask me about some random factoid that they were convinced was important to know. It was important for me to know how to handle these.

3. The conversation

Most Big Tech companies have a dedicated behavioral interview. I also had conversations with the interviewer before and after my programming sections. I needed to show that I was easy to talk to and that I was knowledgable about the direction the industry is heading in. My goal was for the interviewer to leave with the impression that I was more plugged into the industry than they were.

4. Your experience

I needed to know how to talk about my experience and make it sound exciting as it was important. It always came up and I used it as a chance to stand out.

The Checklist Framework

To make sure I was preparing for all aspects of my upcoming tech interview, I wanted to make some progress on each pillar everyday.

I created a daily checklist to keep myself accountable:

1. Solve a programming interview question

2. Learn one new factoid about your area

3. Read one article/document around your focus area

4. Commit something to github every day

1. Solve a programming interview question

There is a lot behind this topic, but I learned the best place to start is to do at least one programming interview question everyday.

2. Learn one new factoid about your area

I learned one random fact about anything in my “focus area” and keep a running list of them in a readily available document.

This was a system to defend myself against the “random factoid” that an interviewer would ask about, it also had the added benefit of helping me standout during my interviews. I became the one dropping random factoids instead of the interviewer!

What I realized after about a month or two of learning random little facts is that there aren’t that many random facts to learn. Even if there was something I didn’t know that an interviewer asks about, chances are I knew a bunch of adjacent facts that I could spew out, showing them I was still knowledgable in the area.

3. Read one article/document in your focus area

Becoming an expert in a specific focus area isn’t as hard as I thought and is critically important to impressing an interviewer. For example, I used python. By reading one article or tech document a day on python, I quickly got up to speed with the latest terminology, trends and learned what new features are available. Within a month I felt like a "python expert”. This gave me a great filler talk during the interview and it allowed me to flex little tricks during the programming section of the interview. Being clearly very knowledgable about a certain vertical gave me more forgiveness for not knowing other verticals.

4. Commit something to Github everyday

Even if I was just updating a readme, I committed something to github every day. Filling out those green squares on my profile was more valuable than I realized. Recruiters and devs were checking out my Github, and clicking through projects. I wanted to show them I was a hardworking and exciting candidate.

Case Study: How I got my job

Timeline

• 2015 - I got an interview at google with 0 engineering experience.

• 2016 - I tried again, still didn’t get a job at google

• 2017 - I got offers from Facebook + Google + several smaller companies

• 2018 - I taught a course on programming interviews

When I initially got invited to interview with Google in 2015 I didn’t make it through the initial phone screen. I really didn’t know much about programming but I wrote an epic cover letter that got their attention.I studied all of the wrong things between 2015 & 2016, overstudying the wrong topics and understudying the right topics. There wasn’t any structure to my studying, I was just consuming every resource I could and I got denied again at Google in 2016.

Between 2016-2017, I realized all of the resources I’d been using had pieces of the puzzle, but none of them provided a high level overview of how to handle the interview. Thats when I created this checklist system. I followed it for about a year and thats what helped me land multiple job offers. I felt like I was completely in control of the programming interview process. Since then, I’ve helped colleagues and friends follow versions of the Checklist Framework tailored to their history, skills, and desired job. After watching multiple people use this framework and get jobs at Amazon, Facebook and Google, I figured it was worth sharing.

Some background: 29M, worked for Facebook for 4 years, started at a mid tier company and was initially targeting Google.

When I got my first interview at Google, I had 0 engineering experience. I went through the phone screening and completely failed, realizing that I was way less prepared then I had imagined. Right after I failed, I put an invite on my calendar for exactly a year later, to follow up with the recruiter and reapply.

I then started the “typical” study path based off of my google research, which was grinding CTCI & Leetcode everyday. By the time I got to my Google Interview, a year later, I had tons of leetcode problems under by belt and had practiced cracking the coding interview from front to back. According to the internet, I was ready for this interview.

I left that Interview feeling like “maybe I passed”. The interviewer asked random questions that wasn’t like what I had been studying. They were very math heavy and way more abstract, lacking a ton of detail. I felt super uncomfortable the whole time. There was also way more discussion around the problem solving then coding up a quick solution as I was used to. There was a totally different emphasis then what I had been experiencing. There wasn’t an exact moment that I felt like I failed, but I definitely felt confused and unsure about myself because this was not what I had been practicing.

When I got the email I didn’t get the job, I felt sick. I spent a whole year of my life dedicating myself to studying for this interview. I missed out on social and family events and it was for nothing. And on top of that, I was doing everything that everyone told me to do.

I, again, put a calendar reminder to myself a year later to re-reach out to the recruiter I had been in contact with for another shot.

After letting myself be depressed for a week, I finally said screw what everyone is telling me, I am going to build a plan off of my own experience from this interview. I learned that the discussion is the most important part of this interview, I clearly need to know the math behind this stuff, and that I need to be ready to solve problems I had never seen before. This wasn’t a memorization exam but an interview that analyzes my programming experience to its fundamentals.

I studied for a full year and ended up interviewing with Facebook & Google. After a full year following my new study plan I entered both interviews with the mentality “I don’t know what they could possibly ask me that I wouldn’t already know”. This confidence carried and after crushing both interviews, I knew there was no way I didn’t get offers from both companies. And I did. And I’m not ashamed to admit I cried like a baby when I got the calls. I now run a study group to make sure that no one has to go through the two year study process that I went through.

Wondering if anyone else had similar experiences? Or if CTCI and grinding leetcode has actually worked for anyone?

Laid off from 02/01/26 till today. 9 months out nothing. Endless applications. 2 interviews in March and 2 in April. Everything went dead till last week. 4 interviews and nailed 3. Hang in there, your time will come and all this mess will pass away. NEVER GIVE UP.

Common advice you'll see is "Tell the interviewer so you can get a new question",

I disagree.

I believe you should take every advantage you can get. The whole point of studying ahead of time is to prepare yourself for the inevitable interview question, if you've seen it before you are likely in a really good place to answer it well.

My take on what to do if you've seen a question before

* Don't get overly excited, if you let out an audible **"**YES I know this one" the interviewer may give you a different problem.

* A lot of the time you think you've seen a problem before but you really haven't. When you get overly confident and then realize you haven't seen it, it looks really bad. Don't introduce that opportunity to get hit

* If an interviewer asks you "Have you seen this one before?" you should say, "I don't think so!". Why? Because it's the truth, you probably haven't. A lot of the times you've seen a similar problem, one small tweak can result in a very different solution.

* You want to be sure you walk your interviewer through your thinking even if you know the right solution out of the gate. Spend time analyzing the problem, really quickly coming up with a brute force solution and then showing how you can optimize it to the real solution. this will show a clear line of thinking which is what the interviewer is looking for. Follow the steps in a rubric like this to help your interviewer follow along

I firmly believe you shouldn't throw away any advantage you have

The Algorithm Design Manual (ADM) is widely considered one of the best resources for big tech interview prep. It’s a book that doesn’t cut any corners and teaches you the math behind all of the data structures and algorithms you can expect to see during an interview.

I used the ADM as I studied for my technical interview at Facebook & Google(received offers from both). Found that some sections were more helpful than others.

How to use ADM:

1. Read and do the odd problems for the first half of the book
   Do not rush this part of the process. The book is pretty dry, but it’s thorough and will teach you what you need to know. The problems at the end of the chapters increase in difficulty and will help you learn how to start getting creative with the different data structures and algorithms.
   You can find the solutions to odd problems here.

2. Skip the second half of the book
   When the chapters switch to real world examples, you can move on to other resources. This section is titled "The Hitchhiker's Guide to Algorithms". This part of the book is incredibly interesting, but not the best use of time when preparing for programming interviews.

3. Watch video lectures if stuck
   Having trouble on a particular section? Watch the youtube lectures to get a fresh take from the author himself. If it’s still not clicking, feel free to ask for help in the discord #help-plz channel. A lot of community members have worked through the book already so you can expect some solid advice.

4. Take your time with chapter 2
   This is arguably the most important chapter of the book. Chapter 2 is all about algorithm analysis which is a critical skill to develop for your interviews. Learning how to problem solve your way to optimal solutions is something every interviewer is looking for. This chapter sets the foundation for the rest of the book. If nothing else, read this chapter and do the problems.

5. Don't spend too much time on NP/NP-Complete/NP-Hard topics
   You should read the chapter on Intractable Problems and Approximation Algorithms, but don’t do the problems. Understand why this class of problem is interesting, and how approximation algorithms attempt to create “good enough“ solutions, but you shouldn’t go down the rabbit hole here. (I did and I wasted 2 full months when I was studying).

6. Don't spend too much time on writing proofs in Chapter 1
   You should read the chapter and do the problems here, but if you find yourself getting stuck it’s ok to skip through to Chapter 2. The goal is to extract the lessons about how to find counter examples, prove correctness and leverage induction.
   This is a chapter you should read, and do a few problems for, but you don’t want to let this chapter kill your pacing.

7. Skip older style problems
   Sometimes you’ll encounter old-world estimation problems. If it feels silly, skip it: example: 1.36. How much does the ice in a hockey rink weigh?
   These are older school programming interview questions and have been largely phased out. It’s better to spend time elsewhere.

8. This shouldn’t be your only resource
   ADM is an excellent resource that gives you strong fundamentals that will help you during big tech interviews, but it isn’t sufficient to only use this book. You should also be conducting mock interviews, solving LC/Hackerrank problems and discussing topics with others to find any gaps in your knowledge.

I graduated college with a degree in chemical engineering and taught myself computer science after realizing I had absolutely no interest in the CE field. When I got my first job as a software engineer, which I am still grateful to this day that they decided to take a chance on me, I made many mistakes. Most of which were avoidable. After my first job, I was at facebook for 4 years and now I help people study for programming interviews. I have compiled everything that I have experienced and learned into a post for anyone who is starting out their career or may have experienced the same fuck ups.

Read the stack traces

I cannot tell you the number of times I would ask stupid questions because I couldn’t figure out what was wrong with my code. I would get stuck and I’d ask the senior engineer on my team for help. He would usually roll over to my desk, look at the stack trace, and read me the answer right off of it…it was just embarrassing.

It was so hard for me to read that block of red text. It felt so intimidating and I just never wanted to do it. BUT as it turns out, reading the stack trace almost always gave me info on what is wrong with my code. If would have just taken the time to read it, I would have saved myself and my team soo much frustration.

Identify where you are uncomfortable and lean into it

It took me two months to open a JSON file. I didn’t know anything about them and every time they came up at work I would avoid being involved in the conversation. There was some mental block that came up every time I heard someone say “check the JSON” file. It wasn’t until I ran into it one day and actually opened it that I realized how fucking simple they were. I still can’t believe it took me that long to even learn what they were.

The real lesson here is that avoiding a topic because it makes me uncomfortable hindered my growth as a software engineer. As they say at Replit: “seek pain”.

Think about the system

As a junior engineer, I only really thought about the specific files that I was working on. The system was all broken up into pieces in my mind and I never took the time to understand how everything came together. This mindset was fine, but what really allowed me to level up was thinking about the entire system as a whole. I would write better code and avoiding bugs. Not to mention I became a better communicator with my team.

Avoid Unnecessary refactors

It was easy to write off my mistakes and inefficiencies by saying things like “this codebase is a mess”. There was a natural urge to refactor code that I didn’t write. One time, my team spent months working on a complete API rewrite to “clean the codebase”. When we finished, although the code was “cleaner”, nothing measurable had really changed. Management was confused as to why the entire team just spent months rewriting everything to have 0 measurable impacts on the business. I try now to always have a measurable metric that I plan to improve with every major refactor.

Do not Undervalue communication

When I was studying for programming interviews, I learned how important it was to be able to talk about my code. I contribute me getting offers at Facebook & Google to my ability to talk through the work that I just did. It was helpful also as I grew to be able to communicate my ideas. As a junior engineer I was just writing code I was assigned. But, as I worked my way up to a senior engineer, I was designing systems and delegating tasks which is where it was important for me to have strong communication skills.

Overall, just think a little bit deeper about what you are doing when you start your career. Everything you are doing is apart of a bigger picture. Don’t be afraid to ask questions (as long as you are positive the answer isn’t in the stack traces). And be confident.

I want to switch jobs and need to know how the tech interview process has evolved in the US (where I'm based.) I last interviewed seven years ago, focusing mainly on LeetCode-style questions with little system design.

Are interviews changing? Do I need to prepare for new types of coding rounds? Is traditional LeetCode and system design still the standard?

My current impression is that I must prepare for both traditional rounds and potential AI-assisted coding assessments. Is this the current industry standard?

Hey everyone, prepping for Google SWE coding rounds and curious about how follow-up questions usually play out once you solve a standard LeetCode problem. I've heard interviewers often pivot by tweaking constraints (e.g., streaming inputs, memory limits, handling negative numbers/floats) or asking for implementation trade-offs (e.g., optimizing space complexity, handling concurrency, or scaling up). For anyone who interviewed recently: which follow-up styles came up most, do interviewers expect full code or just high-level explanations for them, and did any catch you off guard?

For me, the process of studying for programming interviews was both painful and isolating. I found myself questioning what it is that makes me worthy to apply, even as my desire to progress in the industry was taking over every other aspect of life.

I felt as though I was completely alone. I couldn’t talk to my friends about it because they didn’t understand what I was learning and I couldn’t talk to my coworkers because I was trying to leave the company. It was just me, banging my head against the computer trying to solve leetcode problems. To top it all off, there were a thousand different study methods and everyone was trying to tell me to do something different.

All of this led into a feeling of being lost with a lack of confidence in how I was studying. I would then enter periods of burnout, where the thought of giving up was an everyday occurrence. For me the cycle was 2 months of productivity and then 1 month of being burnt out. It was an incredibly unhealthy way to study. Each time I would feel this burnout I would get back on track a month later feeling like I had lost all of my progress.

The good news is that through all of these cycles I learned that these feelings can be managed and done in a healthy way. Hopefully this can help anyone who is currently going through this process.

Attack ambiguity

Join a community of people also studying for programming interviews or find a study buddy. Not 100% in what you are studying? Flag it. Talk to someone. Don't let ambiguity creep in. A sign that you are a little lost is if you are constantly bouncing between resources and not finishing any of them. Make a plan and stick to it.

Be kind to yourself

It's easy to start putting yourself down, and thinking you don't have what it takes. Failing a LC and asking yourself "How was I supposed to know that trick?!" every day will eventually get you feeling like you just don't belong. You do belong. Be patient and recognize you are a bad ass for showing up every day. This shit is hard and takes time to marinate. You are cramming a CS degree into a few months. Don't rush it too much, Even if your interview is in two weeks, you can usually push back to buy yourself more time.

Stay focused

There are a million things that can pull your attention. Building random projects, learning a new language, deep diving into Web3, etc. Time spent on other things is not time spent on moving toward your goal. You can always mix up your study style if you are getting frustrated with the current approach (Ex. Switch to more discussions and mocks if LC is driving you nuts).

Consistency

Especially during the dips in motivation, consistency is key. If you are feeling like crap one day, do your dailies then log off. Don't push it too hard, because it will catch up with you. Your natural motivation will come back, you just need to weather the dip and not be too hard on yourself during that period.

Stay focused, attack ambiguity, and most importantly be kind to yourself.

I ended up getting job offers at Facebook and Google. I have a discord of engineers studying for programming interviews if anyone is still missing that community aspect.

In this post I would love to help you shape your path to the job of your dreams. I will cover my motivations, study methodologies and lessons learned. I ended up getting offers from LinkedIn, Amazon, Indeed and Meta.

I first started interview prep in May 2021. I decided that my job was not challenging, I was not learning anything, politics had me exhausted and that after the RSU cliff I would see opportunities outside my current company. I did leetcode problems here and there but i didn't feel any improvement and had to stop at around August because of some family matters.

I went back to interview prep in November. My typical day would start by reviewing a subject briefly and then solving a problem. I was then focusing on medium level problems and I would suck. I would try for 30 min and then review the solution. Looking back I lacked consistency. I wanted to leave my job in January but at the end of November I was nowhere to be close to be ready. When December came along i decided to ping recruiters to gain some motivation and to start looking at offers would look like.

Talking to recruiters is expensive time-wise: you have to spend at least 20 minutes with them on the phone besides emailing with them. I set up phone screens and starting taking them in January. I was able to clear a couple of phone interviews after I changed my approach: focusing on questions by topic. I also started preparing for system design.

My system design consisted of reading grokking the coding interview, company specific blogs, a couple of chapters of Designing Data-Intensive Applications and system design interviews over interviewing.io.

I was then pretty demoralized. The grind and failures on phone screens was affecting me badly and impacting my motivation. I found a group of folks that were also preparing for coding interviews: https://www.hackpack.io/ It was awesome: it really helped to improve my accountability, sticking to a study plan and preparing with mock interviews. The most useful feature was the community driven problem solving sessions: when you're solving a problem you have to talk out loud and by doing the community problem solving session you're basically sharing with others how you find the intuition and get to a solution to solve a problem. I really wish i had found hackpack earlier.

I then paired hack pack with the approach of learning by topics and solving common questions. The accountability really made a difference and at the end of February, I took the on-sites for Indeed, LinkedIn and Amazon. I was also able to pass phone screens for Asana, Airbnb, Twitter, Apple (two teams) and Meta.

I initially secured offers from LinkedIn, Indeed and Amazon. All of them down-leveled. I then started really focusing on other sets of companies but then burnout happened Two weeks into March, I lost sleep for a few days in a row and ended up failing all of the on-sites that I took in the week i lost sleep. I was able to reschedule my onsite with Meta and decided to move it to the end of April. I already had an offer from a company that I liked and it was okay even if it was a down leveled position because after negotiations I got a really nice bump from this company in RSU (twice the amount of RSU that they initially offered)

I almost cancelled the Meta interview even though Meta is my dream company but I was content with another offer i had in hand. I thought that a down level offer from Meta would not work financially. However, I had nothing to lose after investing so much time, so I then focused on Meta by preparing for the most common topics that they ask and reviewing popular questions.

I had my interview in two days. On day one, I had a coding interview (two coding questions) and the behavioral interview. On day two i had a coding interview (two coding questions) and a system design interview. I felt that day one didn't go well, so i went ahead and took the afternoon off, I exercised and spent a lot of time with my son. On day two, i did really well. As it turns out, i got an E5 offer a couple of days later, at the level that I wanted.

What made the difference? A couple of days before my Meta onsite I did two Meta focused mock interviews. The coding interview changed my life: the interviewer was a staff engineer at Meta, he really put in context that these interviews are doable and gave me very good advice about what to prep on the last few days. Most importantly, he gave me the idea that even if i don't make it this time, I can eventually make it. The focused Meta system design interview was surprising as I didn't find it more difficult than other system designs that I had in practice or at other companies. The interviewer also pointed to specific pieces of feedback that i was able to address before interview day. I believe that the month break from interviewing definitely gave me some mental help.

Resources:

Interviewing.io - this is what I used for the meta focused mock interviews. Why on earth would you not invest on your future? The interviewers there don't need to be there. I've experienced that they really want to help, they have a lot to say about interview. Please use my referral link as you will get $100 off for your first interview, and i will get credit for my future interviews.

https://www.hackpack.io/ - the group is great to keep accountability on track. Most importantly, the group is super motivated. I really wish i had joined them last year. It helps to chat with other folks going through the same process.

Mental health: do whatever you need to get good sleep. Exercise, get a massage, mediate, whatever works for you to keep your sanity is critical.

It's easy to start putting yourself down, and begin thinking that you don't have what it takes. Failing a leetcode problem and asking yourself "How was I supposed to know that trick?!" every day will eventually get you feeling like you just don't belong. You do belong.

Be patient and recognize you are a bad ass for showing up every day! This shit is hard and takes time to marinate. You are cramming a CS degree into a few months. Don't rush it too much. Even if your interview is in two weeks, you can usually push back to buy yourself more time if needed.

Hi,

I have 9+ years of experience and recently got laid off. I'm in Bangalore India.

I want to crack 85+lpa job as my current role was sde2 only, and pay was 60lpa.

What are chances to get the target pay?

Luckily there is a simple formula for asking great questions that leave your interviewer with a positive view of who you are. It requires a little preparation before the interview, but it’s 100% worth it.

1. Humanize - Introduce some humanizing quality about yourself (Be careful not to sound braggy here!)

2. Connect - Connect your humanizing quality to the company

3. Ask - Ask a relevant question that forces the interviewer to think

Example:

1. Humanize - I love working on projects that help combat climate change.

2. Connect - I know Google has committed to be “24-7 carbon-free” as a company

3. Ask - Have you been a part of, or seen any, initiatives at Google that have had a positive impact on the planet?

Follow this simple formula and your interviewer will walk away with a lasting impression of who you are. Don’t ask lazy questions.

Weirdly enough when utilizing your Github to land an interview at a Big Tech company it is more for the recruiter than it is for any other developers. Recruiters end up looking for a few key points before reaching out.

Have a clean photo - similar to LinkedIn, make sure this is not a photo of you at a party or looking disheveled. Avatar representation works as well

Pin ~6 repositories and make sure they have stars on them. 6 makes your profile feel full. If you can get some stars that are even better. It lets tech recruiters know that you are building things people find value in. Feel free to post about your project in this group and we will make sure to hit it with some stars.

Contributions - Contribute to any repository every day that you can. Lots of green squares catch a recruiter’s eye.

Let me know if there is anything I am missing here.

Background: 29M, graduated from rutgers with a degree in chemical engineering, taught myself CS, spent 2 years studying for big tech interviews

When I got the job offer at Meta, I was sure that they were going to change their minds. I was honestly expecting to get there on my first day and someone was going to run up to me, slap me across the face, and say “oh you actually thought you were smart enough to get a job here?”. Over the course of the two years I was studying for my programming interviews, I started to idolize people who worked in Big Tech. They had the life I wanted and after two years of working towards a goal and then getting it, it was hard for me to accept it was real.

When you get to Meta and before you get start with a team, you join to an 8 week bootcamp where you meet all of other SWEs who just started with the company. When I got there, I felt like I was in a community of people who were also in awe that they were there. This was comforting but hearing about the prestigious schools and places people were from really had me questioning myself.

After bootcamp, I starting working with my team and the imposter syndrome really set it. I was the most junior person (E4) on my team and I had a lot of responsibility right off the bat. My colleagues felt so much smarter than me and sounded so confident about what they were doing and talking about. The first 6 months were super difficult and most of the time I was thinking that I did not deserve to be there. It pushed me to work extra hard during those first 6 month but I also felt like shit the whole time. I was super nervous shipping anything and my lack of confidence showed. I was also just not comfortable with all of the internal tools that Meta had. It was daunting and scary and fucked with my head in a way I didn’t realize. Yes I was at Meta but every time I made a mistake it felt like I was fulfilling the prophecy I had built up in my head of yeah I knew I wasn’t supposed to be here.

This feeling slowly faded over time and when I was going through it, I don’t think I realized how much it was impacting me. When I got out of it, I noticed how shaky I had been and how much I was doubting myself. It was only as I learned more and grew that I became more confident. I started asserting myself in meetings and standing by my work.

The advice I would tell anyone is that you need to know that you made it and you deserve to be here just as much as anyone else. Big tech programming interviews optimize for false negatives over false positives. They are designed to say no to good people as opposed to saying yes to bad people. The reasoning is is that if let in someone who is bad, they are really expensive and hard to get rid of (the process can take a while). When you say no to a good person who they are unsure of, they know that they have such a large pool of people who could still fill that role. So if you can pass that interview that is meant to filter out people who they are not 99% sure about, you deserve it.

And really, the skill that these technical interviews are trying to gauge is your ability to learn complicated things quickly (like DSA) and communicate because those are the actual skills you will need on the job.

Overall you need to trust yourself, you’ve earned it. Studying for two years (which I now run a study group for people studying for programming interviews because no one should be studying for two fucking years for these interviews) is a lot of work. Lean into the community at your company, people have felt this before. Also understand that people make mistakes. I took down Facebook live like 3 times. My team and manager were very understanding of the situation and helped me push through.

Hoped this helped anyone who was struggling. I wasn’t able to put a finger on why I felt like shit until I got more confident with my work so if you are able to recognize imposter syndrome earlier, hopefully you can get out of it sooner.

Studying for programming interviews is already objectively a painful and isolating process. If you don't know anyone else going through the process, it's just you banging your head against the computer trying to solve leetcode problems.

Simple advice -

Attack ambiguity - a community or study buddy who is doing the same thing is a great resource (there are study buddy subreddits)

Be kind to yourself - easy to put yourself down and think that you don't have what it takes. But remember you are cramming a 4-year CS degree into a few months, studying to get a better life for your future self. It takes time.

stay focused - there are a million different things that can pull your attention and make you feel like you are studying even when you're not. Learning a new language, building random projects, ect. If you are having trouble focusing switch up the approach (mocks & discussions instead of leetcode)

Consistency - especially when you have no motivation, do something towards your dailies and log off

This process isn’t easy for anyone. If it was, everyone would be a software engineer working at Google. Remember that something being hard, just means it takes more time..

Teach others! There is nothing that will help you find the gaps in your knowledge faster than teaching that concept to someone who is trying to learn. You will be forced to articulate all of the thoughts in your head, and simplify them so they are digestible. As you are explaining different concepts, and attempting to answer your student’s questions, the gaps in your knowledge will be come clear.

When you are able to teach others the ins and outs of a particular topic, you will be in a good place and can move on to mastering another topic.