Interview Experience - 100 - Google | Software Development Engineer | L3

Summary:

• 📌 Job Role: Software Development Engineer

• 🔢 Number of Rounds: 5

• 📜 Offer Status: Offer

• 📍 Location: Bangalore

• 👤 Candidate Name: Not disclosing due to signed NDA

---

Interview Process

A Google recruiter reached out to me initially. We had a brief discussion where I was informed that I’d be undergoing a phone screen. However, based on my profile and after some internal discussion, my recruiter decided to push for skipping the phone screen and moving me directly to the onsite interviews.

All five rounds (four technical interviews and one Googleyness round) were scheduled on five consecutive days. Each interview was conducted remotely and spanned approximately 45 minutes.

---

Preparation Guide

I began my preparations about 3 months before the interview process started. Over that period, I solved approximately 250 Leetcode questions — broken down as:

• 50 Easy

• 140 Medium

• 60 Hard

Besides regular problem-solving, I also invested significant time in reading through previous Google interview experiences. One strong recommendation I have is to take Leetcode Premium and practice company-specific tagged questions. While I didn’t get any question directly repeated (except for one), this practice helped me become familiar with the pattern and difficulty of questions I could expect.

---

Interview Rounds

---

Round 1: First onsite-interview

• Duration: 45 minutes

• Difficulty Level: Medium

Experience:

This round started off well. I was able to arrive at the optimal approach within the first 10 minutes. However, I made the mistake of spending too much time explaining my thought process and writing pseudo-code. While this showed structured thinking, it left me with less time for actual implementation and edge-case discussion.

Eventually, I finished coding and had a brief discussion around the solution, but there wasn't enough time to address the second problem the interviewer had planned.

Problem Asked:

• You are given two arrays, appointmentTime and appointmentDuration, and an integer numRooms. Each room has an ID from 0 to n-1. A room can host only one appointment at a time. Assign appointments to the available room with the smallest ID. Return the ID of the room that hosts the maximum number of appointments.

Key Learnings:

• Don’t over-invest time in pseudo-code or explanation.

• Time management during interviews is key. Transition to coding early.

• Try to reserve time for handling a second question if one is likely to be asked.

---

Round 2: Second onsite-interview

• Duration: 45 minutes

• Difficulty Level: Hard

Experience:

This was the strongest round for me. I quickly arrived at the optimal approach in about 15 minutes and skipped writing pseudo-code to jump directly into coding. This saved time and allowed a deep discussion of edge cases and performance.

The interviewer asked for the worst-case time complexity, which was tricky. After some back-and-forth, I landed on the right answer. I wrapped up both implementation and discussion in about 40 minutes, after which the interviewer ended the session early with positive feedback.

The only constructive comment was regarding variable naming in code — a reminder that readability also gets evaluated.

Problem Asked:

• Given a highway of length m with n+1 lanes. A frog is trying to cross the highway and can move left, right, up, or stay in its lane. There are k cars with known {laneNumber, initialPosition, velocity}. Each car moves with unit velocity in either direction and exits the frame permanently. Find the minimum time required for the frog to cross and also calculate the worst-case time complexity. Assume lane 0 and lane n are empty.

Key Learnings:

• Prioritize readable and clean code, especially variable names.

• Prepare for time-complexity discussions — even for simulation-style problems.

• Avoid unnecessary overhead like pseudo-code unless asked.

---

Round 3: Third onsite-interview

• Duration: 45 minutes

• Difficulty Level: Easy to Medium

Experience:

This was the easiest of all the interviews. Both questions were very familiar to me, as I had practiced similar ones during my Leetcode prep.

I was able to quickly code and test both problems, leaving some time for additional discussion around improvements and edge cases. The interviewer seemed satisfied and there were no major follow-ups.

Problems Asked:

1. First Bad Commit

   • You’re given a list of commits. One of them is bad, and all commits after that are also bad. Use isBad(commit#) to find the first bad commit.
     (Exactly like First Bad Version)

2. Word Break II Variant

   • Given a dictionary and a string, return all possible sentences that can be formed.
     (Very similar to Word Break II)

Key Learnings:

• Practicing known Leetcode problems can help you stay calm during easier rounds.

• Don’t relax even if questions seem straightforward — stay structured in your response.

---

Round 4: Fourth onsite-interview

• Duration: 45 minutes

• Difficulty Level: Hard

Experience:

This was hands-down the toughest round — not because it was a traditional DSA problem, but because it was more of a systems puzzle.

The problem itself was framed loosely, which made it harder to get started. I spent the majority of the time understanding the constraints and exploring different directions. Eventually, I arrived at an acceptable solution and just managed to finish coding in time.

There wasn’t enough time to discuss time-complexity or optimizations, but the interviewer seemed content with the direction and acknowledged the approach as valid.

Problem Asked:

• You are on a computer (Main-computer) in a network of machines, each with a unique identifier (MAC address from A-Z).
  You can’t directly access any machine, but you can send a program that each computer installs.
  This program can send(string) to its immediate neighbors (neighbors are unknown and connections are implicit). It also has a receive() function to get strings from neighbors.
  Write a receive() function such that the Main-computer can eventually output the total number of computers in the network.

Key Learnings:

• Be ready for non-standard problems — not all rounds test only DSA.

• Don’t panic if a problem feels vague — clarify and iterate through potential designs.

• Interviewers may value your thought process even more than a perfectly polished solution.

---

Round 5: Googleyness Round

• Duration: ~45 minutes

• Difficulty Level: N/A

Experience:

This round was more behavioral in nature. The discussion revolved around team collaboration, project ownership, dealing with conflicts, and working under tight deadlines. There were no technical questions in this round.

Key Learnings:

• Be prepared with real-life examples that demonstrate Google’s core values — such as collaboration, humility, and problem-solving under pressure.

---

Final Thoughts

Looking back, I believe these things contributed the most to a successful outcome:

• Practicing company-specific questions on Leetcode Premium gave me a solid sense of the expected difficulty level.

• Reading interview experiences helped me mentally prepare for different kinds of questions — including tricky puzzles and simulation-heavy problems.

• Prioritizing clarity in code and explanations definitely helped, though I could’ve improved on variable naming.

• One underrated skill is time management within interviews. Balancing approach discussion, code writing, and test case handling is key to acing technical rounds.

---

If you're targeting a role at Google or a similar tech company, my advice would be to focus not just on problem-solving but also on code quality, communication, and structured thinking. And of course, be prepared for curveballs — not every round will stick to textbook DSA.

Good luck!