Google | L4 | SWE 3 | India | Interview Experience & Journey | A Guide for DSA Dummies Like Me

My Google L4 Interview Experience

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:

  • Three DSA rounds + One Googliness round
  • Two DSA rounds + One System Design round + One Googliness round
    I opted for the three DSA rounds and one Googliness round format.

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.


DSA round format & suggestions.

  • 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.


Coding Enviornment

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.


My Interview Preparation Journey

image

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.

Understanding My Starting Point

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.

The Nature of Google Interviews

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.

My Preparation Strategy

1. Focusing on Medium & Hard Problems

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.

2. Simulating Interviews

To improve my performance, I conducted mock interviews with myself. I recorded my screen and webcam, mimicking an actual interview:

  • Reading the problem statement aloud
  • Asking clarifying questions
  • Identifying constraints
  • Discussing input-output formats
  • Exploring possible data structures and algorithms

This approach helped me build confidence and refine my problem-solving skills under pressure.

3. Deep-Diving Into Advanced Concepts

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:

  • Segment Trees & Fenwick Trees for range updates
  • Dynamic Programming with space optimization techniques
  • Memoization & Recursion
  • Disjoint Set Rollbacks for graph-related problems

For each topic, I followed a structured approach:

  1. Watched conceptual videos for clarity
  2. Solved fundamental problems on that topic
  3. Attempted more advanced and challenging variations

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.

4. Solving Hard Problems Strategically

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.

Keeping Track of Progress

image

To ensure continuous improvement, I maintained a text document where I logged:

  • Problems I solved
  • Average time taken per problem
  • Concepts I struggled with
  • Areas needing further study

Whenever I encountered a weak spot, I watched targeted videos and practiced additional problems to strengthen that concept.

Visualization & Algorithmic Thinking

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.

Avoiding Regrets

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.

Useful Tools & Extensions

  • LeetCode Premium: Though it didn’t provide perfectly accurate previous Google questions, it saved me time by consolidating problems in one place.
  • Zerotrac Extension: Helped me practice problems above my contest rating (e.g., if my rating was 1800, I practiced problems rated 1900–2000).
  • Leetcode Extension for Likes/Dislikes: Helped me avoid poorly-worded problems unless they were frequently asked in Google interviews.

Final Takeaway From Preperation Strategy

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.


Getting Noticed by Recruiters: What Worked for Me

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.


1 Nov, 2024

Phone Screen Interview

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:

  • I handled an edge case where certain elements had unique constraints.
  • I adjusted my approach to extract additional insights from the computed results.
  • When the problem constraints changed, I proposed a different algorithmic strategy, which the interviewer was satisfied with.

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.


Dec, 2024

Onsite Interviews

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.

Onsite Round 1: DSA

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:

  • If you know how to find the longest cycle in an undirected graph, you should be able to solve this follow-up.

Onsite Round 2: DSA

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.

Onsite Round 3: DSA

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:

  • Counting the number of distinct components.
  • Determining the size of each component.
  • Identifying unique patterns among the components.

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.


10 Jan, 2025

Googliness Round

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:

  • How do you handle conflicts in a team?
  • How would you mentor a new intern?

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.


What I Did Well

✅ 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.


Areas for Improvement

  • Clarity in Explanation: In Round 1, I could have explained my approach more clearly instead of making it sound complicated.
  • Custom Inputs: I should have come up with more test cases rather than relying only on what the interviewer provided.
  • Assertions in Code: Adding assert statements would have made my code look cleaner and more structured.

Final Thoughts on Preparation

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 quality problems you solve, the higher your chances of cracking the process.
  • If you’re lucky, you might solve just 80-100 problems and get a familiar one in your interview.
  • But if you’re unlucky, even after solving 1000 problems, the interviewer might throw a competitive programming-style problem at you.
  • By the time of my first onsite interview, I had solved 1100+ LeetCode problems.
  • For Google, I'd suggest covering problems posted in the discussion section. Here’s a link to my such post: Google Interview Question Compilation

The more high-quality problems you solve, the less dependent you are on luck.

How to Improve Your Interview Performance

  1. Give LeetCode contests: They help you work under time pressure. While contests today are full of cheaters, they’re still a good way to practice.
  2. Mock interviews with friends: Ask a friend to take your interview.
  3. Record yourself: Use a webcam to record your mock interviews and analyze:
    • Where you did well
    • Where you struggled
    • Where you could improve
  4. Improve articulation: Are you able to clearly explain your approach? If not, practice thinking out loud while coding.

20th Feb, 2025

Team Match Process

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.


25th Feb, 2025

Compensation Discussion

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 🎯


Final Words

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.

Leetcode… Google… Inner peace. The grind is inevitable

image

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

Comments (83)