I'm a backend engineer with over five years of experience in the IT industry. Currently, I work at a tech giant.
Ever since I was a teen, Google had been my dream. But due to some unfortunate circumstances, I couldn't clear IIT-JEE, which meant I had to join a tier-3 college. In our college, only mass recruiters and a handful of startups visited for placements.
During my 6th semester, I got underconfident, and at one point, I even doubted if a mass recruiter would hire me. Luckily, I managed to crack my first company, a startup, which paid me twice the amount of what mass recruiters were offering.
After working at the startup for a few years, I wanted to join the big leagues—Google, Amazon, Facebook, Microsoft. But since my college was tier-3 and my company was not well-known, no recruiter ever showed interest in my profile.
I then joined a mid-sized Indian company. After working there for about 1.5 years, I started getting noticed by recruiters since my company had some brand recognition.
In 2022, a Google recruiter reached out to me for a hiring role, but I was given only three weeks to prepare for DSA. I was underprepared and got eliminated in the phone screen itself. Since then, big tech interviews—especially Google—felt like a nightmare to me.
Eventually, I cracked one tech giant, but even then, I always felt that Google was out of my league. After working at my current company for a few years, I made a resolution—2024 would be the year I'd get into Google. I decided to give myself one full year to become the best I could be at DSA.
After nine months of intense DSA prep, I started feeling saturated. A friend then suggested that I was already over-prepared—what I needed now was luck, not more LeetCode problems.
For Google's L4 level, there are two possible interview structures:
Additionally, I’ve seen that for some candidates, the phone screen round can be optional based on their previous interview experience with Google or if they have tight deadlines due to competing offers.
With that mindset, I went for the interview.
Each DSA round lasts 45 minutes, with about 5-10 minutes spent on introductions and final discussions, leaving roughly 36-38 minutes for solving the problem.
Start by understanding the problem and reiterate your understanding to the interviewer. Validate it with multiple input-output examples to ensure clarity.
Try to relate the problem to concepts you have solved before, as this can help in quickly identifying an approach.
Before jumping into coding, discuss your approach in detail. Cover both the happy path and edge cases.
If the interviewer is satisfied with your approach, clearly state the time and space complexity before writing code.
While coding, avoid long silences. Keep explaining your thought process, even if the interviewer isn't responding.
Use a programming language you're most comfortable with. Python, for example, helps in writing code faster.
If you forget a specific implementation detail, leave a comment and mention that you'll come back to it later.
Writing 3-4 lines in plain English before starting the code can help make your approach clearer to the interviewer.
Keep your code modular and structured well to improve readability and maintainability.
After coding, dry-run your solution using different test cases, preferably your own, not just the ones provided by the interviewer.
If there’s another approach to solving the problem, mention it. It's always good to discuss multiple approaches.
The problem format is not fixed. You might get one easy problem with multiple follow-ups, two medium problems, or one hard problem.
During a Google interview, you'll either be given a Google Doc to write code or an online text editor similar to Sublime Text. The online editor (not Google Docs) supports syntax highlighting, displaying keywords in different colors.
In both cases, you won’t be able to execute the code—you only write it. Once you're done, don’t immediately say you’ve finished. Instead, walk through test cases manually. Start with one input scenario, analyze it, then take another and verify your logic. Once you're confident your solution handles edge cases correctly, let the interviewer know you’re done. Remember, execution isn’t an option, so your focus should be on correctness and clarity.

In this section, I want to share my interview preparation strategy—what I did, how I did it, and some key takeaways that can help you in your journey.
Since I was already working at a tech giant, I had a solid grasp of data structures and algorithms, including advanced concepts like heaps, dynamic programming, and backtracking. However, my knowledge was not in-depth. My earlier problem-solving experience was mostly limited to well-known problems from popular interview sheets, but I knew that preparing for Google required me to aim for the highest level.
Google interviews are not inherently impossible; difficulty can vary based on luck. On a good day, you might get manageable problems, but on a bad day, you could face exceptionally hard ones. Since I was determined to secure an offer, I prepared for the worst-case scenario—solving the hardest problems efficiently.
I rarely solved easy problems, as my fundamentals were already covered. The only times I attempted them were during contests or daily problems. Instead, I concentrated on medium-level problems, ensuring I could solve them within 20–25 minutes. Once comfortable, I moved on to hard problems.
To improve my performance, I conducted mock interviews with myself. I recorded my screen and webcam, mimicking an actual interview:
This approach helped me build confidence and refine my problem-solving skills under pressure.
There were some areas I had limited exposure to, like Disjoint Set Union (DSU). Though I was aware of it, I didn't fully grasp its application in complex graph problems. Once I mastered it, many tough graph problems became much easier.
I also studied:
For each topic, I followed a structured approach:
Once I solved difficult problems on these topics, they became intuitive. Many advanced concepts have only a few standard problems, meaning that if a tough problem appeared in an interview, there was a high chance I had already encountered it.
After mastering medium problems, I transitioned to solving hard problems. Google’s hardest interview questions often require deep insights, making it difficult to derive a solution on the spot. To mitigate this risk, I ensured I had practiced enough hard problems beforehand.
I also participated in LeetCode contests initially, but over time, I noticed a surge in cheaters and AI-assisted solutions, which impacted rankings. To maintain focus, I shifted entirely to solving previously asked interview questions, reviewing my weak areas, and revising my concepts.

To ensure continuous improvement, I maintained a text document where I logged:
Whenever I encountered a weak spot, I watched targeted videos and practiced additional problems to strengthen that concept.
The ultimate goal of problem-solving is to visualize the solution before coding. As I advanced, I reached a point where I could mentally map out how a data structure would evolve as my algorithm executed. This visualization ability significantly boosted my efficiency in solving problems.
I wanted to be fully prepared so that, even if I got rejected due to luck, I wouldn’t regret not working hard enough. I was determined not to face a situation where I wished I had put in more effort.
The best way to prepare is by solving problems that other candidates encountered in Google’s on-site or phone screen rounds. Google often repeats questions over time—I even noticed a 2024 question that was also asked in 2022. By focusing on previously asked questions and continuously refining my problem-solving skills, I maximized my chances of success.
To get noticed by recruiters, especially if you're from a lesser-known college or company, there are a few things that can significantly improve your chances.
First, timing matters. If you're from a no-name college or company, waiting until you have at least 3+ years of experience can make a big difference. Recruiters are more likely to reach out once you’ve built a solid track record.
Keeping an active LinkedIn profile is crucial. Regularly update your profile, engage with posts, and share insights related to your work. Visibility plays a key role in getting noticed. Along with that, networking strategically can open doors—connecting with multiple people from your target company increases the chances of finding a referral or getting noticed by recruiters.
When it comes to referrals, reaching out to non-SWE employees can be more effective. SWE folks often receive too many referral requests, making it easy for your message to get lost. On the other hand, employees in non-engineering roles are usually more responsive.
Turning on "Open to Work" on LinkedIn and actively using job portals like Naukri can also help. Many recruiters search for candidates on these platforms, so keeping your profile updated increases the chances of getting inbound opportunities.
Lastly, having strong projects on your resume makes a difference. I built WhatsApp and Reddit clones, which showcased my skills in a tangible way. Recruiters often look for solid project experience, especially when considering candidates from lesser-known backgrounds.
Doing these things won’t guarantee an opportunity overnight, but they significantly improve the chances of getting noticed by top tech companies.
In the first phone screen, the interviewer started with a basic introduction. After that, he shared a problem on Google Docs. If you were familiar with multi-source BFS, you could solve it easily. The problem revolved around multi-source BFS concept.
The problem required applying graph traversal techniques to analyze relationships within a dataset. I quickly identified that multi-source BFS would be an efficient approach and implemented the solution.
The interviewer then introduced several follow-ups to test my adaptability:
It took about two weeks for the recruiter to get back with feedback. The response was exceptionally positive, and the recruiter encouraged me to proceed with the onsite rounds. She then asked when I’d be ready. Again, I felt I wasn’t fully prepared, so I took one month to brush up.
I fell sick in between and had to be hospitalized. When I got back, it felt like I had forgotten everything, and it took me a week to regain my DSA skills. My onsite interviews were scheduled for the last week of December. I was busy grinding DSA problems that Google had previously asked.
The first problem was related to graphs. If you are well-versed with when to use BFS over DFS (and vice versa), this would have been easy.
The follow-up was:
This wasn’t a standard DSA problem; it was a mix of DSA and system design, focusing on queues. If you’ve ever written code dealing with asynchronous calls, this would have been a cakewalk.
The problem required identifying connected components within a structured dataset. I ensured not to assume the input format and clarified whether I needed to determine the structure myself. The interviewer asked me to come up with my own test cases to verify my approach.
The follow-ups focused on extending the solution:
While the initial problem was manageable, the follow-ups required deeper insights and optimizations. Fortunately, my prior practice helped me recognize similar patterns and adapt efficiently.
Once my onsite rounds were over, I had the Googliness interview in the first week of the New Year. I expected behavioral and hypothetical discussions, but my interviewer initially thought it was another technical round and gave me a DSA problem. I clarified that it was a Googliness round, and he apologized, taking some time to go through my resume.
We then had a 30-minute deep dive into one of my personal projects listed on my resume. Interestingly, even though I had applied for a backend role, the discussion focused on UI/UX design. This made me realize that you should be fully prepared to discuss every detail of your resume, regardless of your target role.
After that, I was asked some standard behavioral questions, such as:
Since the Googliness round is equally important as technical rounds, it’s essential to have structured answers ready for behavioral questions. Your responses should highlight teamwork, leadership, adaptability, and problem-solving mindset.
✅ Code Quality: My code was clean, modular, and well-structured.
✅ Communication: I actively discussed my thought process with the interviewer, incorporated feedback, and dry-ran edge cases.
✅ Time & Space Complexity: My time and space complexity was always correct in all rounds. In fact, I even corrected the interviewer once when he mentioned the wrong complexity for an approach.
✅ Minimal Hints: I took 0 hints, ensuring I was driving the solution independently.
There’s endless debate about quality vs. quantity when it comes to DSA prep. How many problems do you need to solve to crack Google? Some say 100, some say 200, others say 1000.
For me, I’ve always believed:
The more high-quality problems you solve, the less dependent you are on luck.
Three days after my onsite interviews, my recruiter mentioned that my feedback was positive and that my profile would be sent for team matching.
The team match process took around 40 days. Initially, I was supposed to have a call with one team, but they declined a day before the actual call. Then, I had a call with another team, which became my first official team match call.
During the discussion, the hiring manager and I aligned well with the work I had done in the past. We both agreed that this would be a good fit, and the manager gave the green light. After this, my packet was sent to the Hiring Committee (HC) for approval.
I was particular about joining at the L4 level only. There was a high chance that the HC might approve me for L3 instead, but luckily, my profile was approved for L4 one week after the team match process.
The next day, we had a compensation discussion. I shared my expected CTC, and the recruiter matched my expectations. I wanted a higher base salary, so I adjusted the signing bonus and equity accordingly.
After two days, I finally received my official offer from Google! 🚀
I hope this experience helps others preparing for their Google interviews. Here’s the link to my compensation post: Google L4 SWE-3 India 🎯
For those preparing for Google interviews, I’d strongly suggest not relying solely on the "Google" tagged questions on LeetCode premium feature. These questions are often asked once in OA or unnecessarily hard and have a very low chance of appearing in onsite interviews. Instead, prioritize the problems shared by other candidates in the Discuss section—they are far more representative of actual interview difficulty.
From my experience, most of my interview questions were medium difficulty, though two rounds had hard follow-ups. However, with enough practice, I had encountered a variety of problems, which helped me connect concepts from previously solved problems to tackle new ones efficiently.
After years of setbacks, I finally cracked Google. If you’re struggling, don’t give up. Your time will come. Keep improving, keep solving good problems, and eventually, luck will favor you.
I'll share the curated list for preparation in the comment section.

Hope this post helps those who are still grinding. Feel free to ask me anything. 🚀