Google SWE Intern Interview Experience — The Key to Nailing Both Rounds

Just finished my Google Software Engineer Intern interview process — two rounds, both passed smoothly. Here’s a detailed breakdown of the real interview content, structure, and the reasoning behind each question. If you’re aiming for a Google internship, you can literally copy this playbook.

🔍 Overview

Google SWE Intern interviews typically have two rounds, both focused on algorithmic problem-solving. You’ll be tested on data structures and fundamental algorithms — dynamic programming, graphs, trees, sorting, and searching. Be prepared to analyze time and space complexity as well.

Important note: Google uses its own text-based coding editor, not Google Docs. When practicing mock interviews, try using a plain-text environment to simulate that experience — no syntax highlighting, no autocomplete.

🧩 Round 1: Meeting Room Scheduling (Minimum Number of Rooms)

This question is fairly standard, but clarifying the problem boundaries upfront is crucial — Google interviewers care a lot about whether you confirm the requirements before coding.

Here’s what I asked first:

Are the time intervals half-open [start, end) or closed [start, end]?
→ This affects whether end == start means overlapping. We assumed half-open intervals.

Can the input be empty? Are zero-length meetings (start == end) valid?

Are times integers? Any upper/lower limits?

Is the input sorted by start_time? (If not, we need to sort first.)

🧠 Solution Approach: Min-Heap

We use a min-heap to track the earliest meeting end time among all currently used rooms.

Steps:

Sort all meetings by start_time (if not already sorted).

Initialize a min-heap storing the end_time of ongoing meetings.

Iterate through each meeting:

If the heap is not empty and heap.top() ≤ current.start_time, a room is free — pop it and push the new end_time.

Otherwise, push current.end_time (we need a new room).

The maximum heap size during iteration equals the minimum number of rooms required.

⏱️ Complexity Analysis

Time: Sorting takes O(N log N); heap operations add another O(N log N) overall.
Space: The heap may hold up to N elements, giving O(N) space complexity.

💬 Round 2: BQ + Coding (Range Sum Query)

The second round started with a few behavioral questions, followed by two coding tasks — the main one being a “Range Sum with Updates” problem.

🗣️ Behavioral Questions (BQ)

Google doesn’t want generic answers. Use the STAR method (Situation, Task, Action, Result).
Here are the three I got:

Tell me about a time you learned from failure.
I shared a project where I skipped edge testing, which caused a production bug. Learned to write test cases before coding.

What if you disagree with a teammate on a technical decision?
I said I’d first understand their reasoning, compare trade-offs like performance and maintainability, and use data or small-scale testing to decide.

Describe a time you helped a teammate improve technically.
I explained how I walked a teammate through dynamic programming step-by-step until he could independently solve similar problems.

⚙️ Coding: Design a Range Sum Data Structure

You need a data structure that supports:

update(index, value)

sumRange(left, right)

🧠 Optimal Solution: Segment Tree

A Segment Tree efficiently handles both range queries and point updates.

Concept:

Leaf nodes represent single array elements.

Internal nodes store the sum of their two children.

Updates propagate upward in O(log N).

Range queries combine partial segments in O(log N).

🔍 Follow-Up Questions