def min_cars(requests: list[tuple[str, int, int]]) -> int:
The round: a car-rental scheduling question in four Google reports from May to August 2026: an L5 phone screen, an L4 AI/ML loop's second round, an L3 onsite round, and a first-round virtual interview. Every version gives a list of rental requests, each with a pickup time and a return time; three of the four also give each request an id. Three ask for the fewest cars that can serve them all; three ask which car serves which request, either filled into a Car object's rental_record or as a map from reservation id to car id. One candidate compared it to LeetCode 253, Meeting Rooms II. Two graded parts.
A request is a tuple (request_id, pickup_time, return_time) with pickup_time < return_time. One car can serve any number of requests that do not overlap. A car returned at time 5 can be picked up again at time 5 (the L5 report states this rule).
Part 1 — the fewest cars
def min_cars(requests: list[tuple[str, int, int]]) -> int: ...
requests = [("r1", 0, 30), ("r2", 5, 10), ("r3", 15, 20)]
answer: 2 (r1 needs its own car; r2 and r3 can share one)
Discussed, not graded: three follow-ups were reported without rules. A fleet capped at K cars, fewer than Part 1's answer: what do you do with the requests that cannot be served? (The report does not say whether it was coded; a reply said implementing it fully on the spot is very hard.) Cars that need maintenance as they approach a mileage limit, each maintenance taking several days (described in a reply by another candidate, whose interviewer only wanted the reasoning). Login logs sharded across servers and regions, a change of scenario that was discussion only. None of them came with rules, so none are graded here.
Notes: the function names, the tuple input, the request ids in every test, and every example are ours. One L5 report starts from "given N cars" and still asks for as few cars as possible; the graded parts create cars as needed (see the clarifications).
Standard explanation — no candidate report records what the interviewer accepted here.
Count the cars created (or the size of the heap) at the end; each car is added only when every existing car is busy, so that count is the minimum fleet. The report gives no answer; this is ours.
The report does not define the goal. Ask what is being optimised (requests served, revenue) before proposing anything. A reply said implementing it fully on the spot is very hard.
The reply says it is tricky because a car can be maintained at the limit or earlier, that the candidate concluded after the interview that it has no clean solution, and that the interviewer only wanted the reasoning. The rules (how miles accrue, whether the limit repeats) are not reported.
Standard explanation — no candidate report records what the interviewer accepted here.
No answer is reported. Our suggestion: ask what the processing is for, then merge shards by timestamp or aggregate per shard and combine (map-reduce style), and allow for clock skew between servers.
Two of the four reports come from loops that passed. The L4 AI/ML candidate solved both parts with a sweep line and was then asked how to process user-login logs sharded across servers and regions; that was discussion only, and the interviewer also said it was hard. The L5 candidate met it as the first phone screen. In the first-round virtual interview the follow-up capped the fleet at K cars, and a reply noted that coding it fully on the spot is very hard. The L3 candidate returned a dict from reservation id to car id and was asked why a dict and how to report the number of cars used; a reply under that post said this question had been coming up a lot, and another candidate there got it with a follow-up about cars that need maintenance after a mileage limit, where the interviewer only wanted the reasoning.
The round: a car-rental scheduling question in four Google reports from May to August 2026: an L5 phone screen, an L4 AI/ML loop's second round, an L3 onsite round, and a first-round virtual interview. Every version gives a list of rental requests, each with a pickup time and a return time; three of the four also give each request an id. Three ask for the fewest cars that can serve them all; three ask which car serves which request, either filled into a Car object's rental_record or as a map from reservation id to car id. One candidate compared it to LeetCode 253, Meeting Rooms II. Two graded parts.
A request is a tuple (request_id, pickup_time, return_time) with pickup_time < return_time. One car can serve any number of requests that do not overlap. A car returned at time 5 can be picked up again at time 5 (the L5 report states this rule).
Part 1 — the fewest cars
def min_cars(requests: list[tuple[str, int, int]]) -> int: ...
requests = [("r1", 0, 30), ("r2", 5, 10), ("r3", 15, 20)]
answer: 2 (r1 needs its own car; r2 and r3 can share one)
Part 2 — which car takes each request
class Car:
def __init__(self, id):
self.id = id
self.rental_record = []
# ...
def assign_cars(requests: list[tuple[str, int, int]]) -> list[Car]: ...
rental_record holds the requests it serves (the request tuples; the tests also accept just the ids). Two requests on one car must not overlap. Car ids only need to be distinct.Car class above; another asked you to design it. One report returned a dict from reservation id to car id instead; that is {rid: car.id for car in cars for rid, _, _ in car.rental_record}.Discussed, not graded: three follow-ups were reported without rules. A fleet capped at K cars, fewer than Part 1's answer: what do you do with the requests that cannot be served? (The report does not say whether it was coded; a reply said implementing it fully on the spot is very hard.) Cars that need maintenance as they approach a mileage limit, each maintenance taking several days (described in a reply by another candidate, whose interviewer only wanted the reasoning). Login logs sharded across servers and regions, a change of scenario that was discussion only. None of them came with rules, so none are graded here.
Notes: the function names, the tuple input, the request ids in every test, and every example are ours. One L5 report starts from "given N cars" and still asks for as few cars as possible; the graded parts create cars as needed (see the clarifications).
How do you know how many cars were used in the end?
Why did you choose a dict for the answer?
If there are at most K cars, and they cannot cover every order, how do you handle it?
Cars need maintenance when they approach a mileage limit, and each maintenance takes y days. How do you find the fewest cars under that constraint?
User login logs are sharded over different servers and regions. How would you process them?
| Approach | Notes |
|---|---|
| Sweep line over pickup and return events, returns before pickups at equal times (gives the count; producing the assignment needs extra bookkeeping). Scanning every car for a free one instead of a heap | correct, but O(n * c)). |
Interviewer hints: In the L4 round the interviewer said the sharded-logs follow-up was hard, and it needed no code. In the reply describing the maintenance follow-up, the interviewer only wanted to hear the candidate's reasoning.
What passers do: Two of the reports come from loops that passed. The L4 candidate solved it with a sweep line. The L5 report says the key is how you sort the requests and reuse cars that are already free.
What candidates did: The L3 candidate used a heap and returned a dict from reservation id to car id. The first-round candidate sorted by pickup time and kept a min-heap of each car's next free time.
Edge cases to test (ours): A return and a pickup at the same time (the L5 rule: same car). Requests given out of order. Many requests over the same hours. No requests.
Send them this page. It is free to read, no account needed.
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 48 Google questions, refreshed monthly from new candidate reports.