← Back to blog Google SDE R1 Debrief: Coding + Deep-Dive BQ
VO Google

Google SDE R1 Debrief: Coding + Deep-Dive BQ

2026-08-12

This debrief covers the two rounds I had for a Google SDE role in R1: one coding round and one pure behavioral round, 45 minutes each. Beyond the problems themselves, I also collected the small-but-useful details of onsite day, travel reimbursement and the flow of getting in and out of the office area. If you're prepping for a Google onsite, I hope this note helps you dial in your pace and mindset.

Interview Overview

R1 had two rounds with a very standard rhythm: the first talks people before code, the second is behavioral throughout. The two interviewers had different backgrounds and clearly different styles.

Round Duration Format Focus
Round 1 (Coding) 45 minutes Self-intro + resume-project chat + live coding Project depth, coding approach, interval-partition modeling
Round 2 (BQ) 45 minutes Pure behavioral, deep dive on projects and collaboration STAR structure, judgment process, teamwork

One takeaway: the project chat in the first half of the coding round is not a formality. The interviewer follows your answers and probes "what specifically did you do." The BQ round digs into your real experience the whole time, so templated answers get exposed fast.

Round 1: The Coding Round

The first interviewer was a native Chinese-speaking engineer, and the pace stayed relaxed throughout. It opened with a self-introduction, then a project chat off my resume: why Google, what the biggest challenge in the project was, and how I solved it. For this stretch, sort out the technical details and your personal contribution for one or two projects ahead of time, because the interviewer chases the details rather than listening to you restate the job description.

After roughly a third of the time on projects, we moved into coding.

Problem: Car-Rental Order Scheduling

Given a set of car-rental orders, each with an order ID, a pickup time, and a return time, assign the orders to a number of cars so that orders on the same car do not overlap in time. Also design a Car class that holds the car and the list of orders assigned to it.

This is essentially an interval-partitioning problem: the goal is to cover all orders with as few cars as possible.

Approach

  1. Sort all orders by pickup time ascending.
  2. Maintain a min-heap holding each car's "earliest available time" (the return time of that car's current last order).
  3. Process each order in turn: look at the car at the top of the heap. If its return time is <= the current order's pickup time, that car has freed up, so reuse it; otherwise every car is still occupied, so open a new car.
  4. After assigning, update that car's available time and push it back onto the heap.

The key during the dry run is to state the boundary out loud: if a return time exactly equals the next order's pickup time, does that count as a conflict? Confirm the convention with the interviewer. The common reading is "you can only pick up after the previous order is returned," meaning <= counts as reusable.

Python Solution

import heapq
from typing import List


class Order:
    """One car-rental order: order ID, pickup time, return time."""

    def __init__(self, order_id: str, pickup: int, ret: int):
        self.order_id = order_id
        self.pickup = pickup
        self.ret = ret


class Car:
    """A car that holds the list of orders assigned to it."""

    def __init__(self, car_id: int):
        self.car_id = car_id
        self.orders: List[Order] = []

    @property
    def available_at(self) -> int:
        """Earliest available time: the last order's return time, or -inf if empty."""
        return self.orders[-1].ret if self.orders else float("-inf")

    def assign(self, order: Order) -> None:
        self.orders.append(order)


def assign_orders(orders: List[Order]) -> List[Car]:
    """Assign orders to as few cars as possible; orders on one car never overlap."""
    # Edge case: no orders, return empty
    if not orders:
        return []

    # Step 1: sort by pickup time ascending
    orders.sort(key=lambda o: o.pickup)

    cars: List[Car] = []
    # Heap elements are (earliest available time, index of the car in cars)
    heap: List[tuple] = []

    for order in orders:
        # Step 2: reuse the top car if it has freed up (return time <= pickup)
        if heap and heap[0][0] <= order.pickup:
            _, idx = heapq.heappop(heap)
            car = cars[idx]
        else:
            # Step 3: otherwise open a new car
            car = Car(car_id=len(cars))
            cars.append(car)
            idx = car.car_id

        # Step 4: after assigning, update availability and push back
        car.assign(order)
        heapq.heappush(heap, (order.ret, idx))

    return cars

Time complexity: O(n log n), sort and heap operations are both logarithmic. Space complexity: O(n); the heap and car list hold at most n elements.

Dry Run Walkthrough

Walk through orders [(A, 1, 4), (B, 2, 5), (C, 4, 6), (D, 7, 8)] (format is order ID, pickup, return):

Step Current order Heap-top available Decision Car state
Handle A(1,4) A heap empty Open Car0 Car0=[A]
Handle B(2,5) B 4 > 2 Open Car1 Car0=[A], Car1=[B]
Handle C(4,6) C 4 <= 4 Reuse Car0 Car0=[A,C], Car1=[B]
Handle D(7,8) D 5 <= 7 Reuse Car1 Car0=[A,C], Car1=[B,D]

Two cars cover everything: Car0 holds A and C, Car1 holds B and D.

Boundaries to raise proactively:

Follow-up: What If There Are at Most K Cars?

The interviewer then asked: what if the fleet has a cap, at most K cars? The point here isn't the code, it's to clarify the business requirement first. Here's how I broke it down at the time:

In implementation, you can cap the heap at K: when the heap already holds K cars and the top car still hasn't freed up, trigger the reject/fail logic above. I didn't rush to write full code here; I laid out the tradeoff so the interviewer could see I align on requirements before I start typing.

Round 2: The BQ Round

The second interviewer was from India, pure BQ throughout, digging deep into resume projects and teamwork. The questions were classic but the probing was fine-grained:

  1. When a teammate initially disagrees with your proposal, how do you win them over?
  2. When multiple tasks compete for resources at once, how do you prioritize?
  3. When an unplanned new opportunity shows up, do you pause your current work to pursue it, and how do you decide?

My takeaway: scoring in the BQ round isn't about a "polished answer," it's about explaining the judgment process:

Other R2 Onsite Info / Logistics

Beyond the problems, onsite day had plenty of flow and reimbursement details, and knowing them ahead saves a lot of hassle:

Prep Tips

Google's two R1 rounds test two different abilities, so prep for them separately.

FAQ

Q1: Does the project chat before coding matter?

A lot, and it's not a formality. The interviewer follows your answers and probes "what specifically you did and how you solved it." Sorting out the technical details and your personal contribution for one or two projects ahead of time beats reciting the job description.

Q2: Why a min-heap for car-rental scheduling instead of scanning every car per order?

Scanning every car to find a free one is O(n^2). A min-heap keyed on each car's "earliest available time" lets you check only the top to decide reuse, giving O(n log n) overall, a clear win at scale and easier to explain out loud.

Q3: If a return time exactly equals the next order's pickup time, is that a conflict?

It depends on the business convention, so confirm with the interviewer. A common rule is "you can only pick up after the previous order is returned," meaning return time <= pickup counts as reusable; using <= in code covers this touching-endpoints case.

Q4: How should I answer the "at most K cars" follow-up?

Clarify the requirement first: if all orders must be fulfilled, return failure the moment a (K+1)-th car is needed; if rejecting orders is allowed, ask whether the goal is keeping high-value orders or maximizing the order count, since each goal calls for a different strategy. Laying out the tradeoff matters more than writing code right away.

Q5: How do I answer the BQ round without getting exposed?

Use real STAR stories and emphasize the judgment process over the conclusion: state the constraints you faced, what you personally did, and the outcome. A fabricated story tends to fall apart on the second layer of probing.

Prepping for Google SDE's coding and BQ rounds? We know how to narrate this kind of interval-modeling problem and the rhythm of a BQ deep dive, and can help you polish both your modeling approach and your STAR stories until they hold up under probing.

Add WeChat Coding0201 now to get a one-on-one custom prep plan.

Contact