Status: Offer Accepted
Position: Software Engineer, L4
Location: Bengaluru, India
Date: Oct-Nov 2025
YoE: ~3.5 Years
Compensation: See full breakdown here

Timeline

• Mid-Sept 2025: Recruiter reached out (Profile shortlisted).
• 7 Oct 2025: Round 1 (DSA – Elimination).
• 13 Oct 2025: Round 2 (DSA – Judgment/Design).
• 15 Oct 2025: Round 3 (Googliness & Leadership).
• 7 Nov 2025: Round 4 (Domain – Android).
• 17 Nov 2025: Team Fitment.
• Late Nov 2025: Offer! 🎉

Preparation Phase

• Optional Session: Google organized a group prep session to explain the process and expectations (Thinking Aloud, Clarifying Assumptions).
• Note: I could not attend due to workload, but it did not affect the evaluation. The session is purely informational.

Round 1: DSA (Elimination)

Focus: Data Structures, Time Complexity, Memory Constraints.

Problem Statement:
I was given a stream of messages, each with a timestamp. The goal was to design a system that:

1. Considers a message "valid" only for 10 seconds (timestamp + 10).
2. Ignores duplicate messages within this validity window.
3. Returns the earliest valid message timestamp at any given moment.

Pattern: Sliding Window + Queue/Deque + Hash Set.

Discussion & Follow-ups:
The interviewer was less interested in the brute force and more interested in handling the "Stream" aspect.

• Constraint: Messages arrive in monotonic timestamp order.
• Memory Bounding: Since it's a stream, we cannot store everything.
  • Approach: Use a Deque (or Queue) to store valid messages. Since timestamps are monotonic, we can efficiently pop messages from the front that are older than current_time - 10.
• Optimization: Aiming for O(1) amortized time for retrieval and cleanup.
• Concurrency: Discussed what happens under high throughput (locking vs. lock-free structures).

LeetCode Mapping:

• Logger Rate Limiter (LC 359) – Closest variation

Round 2: DSA (Judgment/Design)

Focus: Interval Logic, Code Maintainability, Handling Ambiguity.

Problem Statement:
Given a sorted list of intervals [a, b], find the interval in which a specific number x lies.

Evolution of the Solution:

1. Initial: Linear scan.
2. Optimization: Since intervals were sorted by start time, I proposed a Binary Search approach to find the candidate interval efficiently.

Follow-ups (The core evaluation):
The interview quickly shifted to manipulating the data structure:

1. Merge Intervals: How do we handle overlapping intervals?
   • Expectation: Normalize the data first. Merging overlaps makes future queries faster and cleaner.
2. Insert Interval: How to insert a new interval while maintaining the sorted/merged invariant?
   • Expectation: Reason about "neighboring" intervals and merge locally where required.
3. Constraint Optimization: If the interval range is small/bounded, can we make lookup O(1)?
   • Approach: Pre-computation / Direct Indexing (trading space for time).

LeetCode Mapping:

• Merge Intervals (LC 56)
• Insert Interval (LC 57)

Round 3: Googliness & Leadership

Focus: Behavioral, Collaboration, Conflict Resolution.

Standard behavioral questions focused on Google's "Googliness" attributes.

• Themes: Handling disagreements with a manager, working beyond defined scope, and ownership.
• Strategy: I used the STAR Method (Situation, Task, Action, Result).
• Tip: Be honest. Focus on a "learning mindset" rather than just proving you were right.

Round 4: Domain Specific (Android)

Focus: Android Fundamentals, Architecture, Jetpack Compose.

Since I interviewed for an Android role, this was a deep dive into the ecosystem:

• Fundamentals: XML vs. Compose, Lifecycle management.
• Architecture: MVVM patterns, Dependency Injection (Dagger/Hilt).
• Scenario: We discussed real-world architectural decisions from my past projects. This part heavily relied on practical work experience and trade-offs.

Team Fitment

Held later due to manager availability. It was a casual discussion on team alignment, expectations, and current projects.

Key Takeaways for the Community

1. Follow-ups are everything: Solving the base problem is just the entry ticket. The real evaluation happens when they add constraints (memory, time, concurrency).
2. Clarify Constraints: Never assume. Ask about input size, time range, and data types immediately.
3. Verbal Reasoning: In Round 2, I spent a lot of time just discussing the design before coding. This is valued highly.
4. Domain Knowledge: If you are applying for a specific stack (Android/iOS/Frontend), expect a rigorous round on that specific tech, not just DSA.

A Note on AI & Interview Integrity

I’ve heard discussions about candidates using AI tools during online interviews, but based on my experience, that strategy will not work at Google.

Unlike other companies where the focus might be on "passing test cases" in an IDE, Google's process is fundamentally different:

• Coding on a Doc: You write code in a Google Doc, not an IDE. There is no syntax highlighting or auto-complete.
• Process over Syntax: The interviewer is far less interested in a perfect, compilable solution and more interested in how you think.
• Requirement Gathering: The primary focus is how you approach the problem in real life. They expect you to clarify ambiguous requirements before writing a single line of code.
• Explain-as-you-Code: You are expected to explain why you are choosing a specific data structure or logic while you type. It is not enough to just produce the correct code; the "thinking aloud" is what they are evaluating.
• Collaboration: If you get stuck, the interviewer is usually helpful and will nudge you in the right direction—but only if you are communicating. If you are silent, they cannot help you.

I also interviewed at other top tech companies (like Flipkart), but Google stands out because they evaluate your reasoning and approach rather than just the final working solution.

Good luck to everyone preparing! Consistency is key. 🚀

I will create a separate post for my DSA preparation strategy. Regarding specific Google interview preparation, I can create a dedicated post on demand if there is interest (let me know in the comments!), otherwise, there are many existing resources online.