Google OA Interview Experience (2026) - Fill 2D Array, Largest Subarray, Max Cake Area, Compare Strings, Offer

My honest take is that most Google OA candidates should memorize odd- n Siamese cold and write return null for n = 2 . If you get singly even n = 6 on the exam, fall back to a brute-force backtracking that will pass smaller hidden cases and partial-credit you past the wall. I ran out of clean memory on singly even during a practice round and still got maybe 60 percent credit off the odd-case solver alone.

This problem is constructive and does not line up with a clean Google question in our practice set yet. Treat the round as a standalone set piece and move on if the construction does not come to you in five minutes.

Round 2 — Largest Subarray Sum (Kadane)

Problem: Given an integer array nums that may contain negatives, find the contiguous subarray of length at least one with the largest sum and return that sum.

Kadane's algorithm. Keep a running best-ending-here value, reset it to the current element whenever extending it would drop you below the current element, and track the global maximum as you go. Linear time, constant extra space.

The only real trap is handling an all-negative array. A beginner's version that initializes the running max to zero will wrongly return zero on [-3, -1, -2] when the answer is -1 . Initialize both cur and best to nums[0] and the edge case sorts itself out. This is the kind of five-line solution that Google uses to check whether you can spot the off-by-one before coding it. Write two test cases first, then the function.

Google's catalog does not have a direct Kadane question yet either, but the prefix-sum family is represented and the thinking is adjacent.

Round 3 — Maximum Area Serving Cake

Problem: You have an array of cake radii and a number of guests. Cut a single fixed piece size so that every guest gets exactly one piece of that area, and no piece straddles two cakes. Maximize the piece area. Return a floating-point answer.

This is binary search on the answer. The predicate "can we serve everyone a piece of area A" is monotone: if it works at A, it works at any smaller area. Feasibility is a sum over cakes of floor(area i / A) , and you want that total to be at least the guest count. Binary search over A with roughly 60 iterations of floating-point halving gives you enough precision for the 10^-4 tolerance that Google OA typically accepts.

Upper bound for the search is the area of the largest cake, lower bound is a small positive epsilon. Do not try to solve it analytically, it just gets worse. The shape of this problem shows up across Google OAs with different wordings, so the binary-search-on-answer pattern is worth drilling regardless of the cake theme.

No direct binary-search-on-answer question exists under Google in our set at the moment, so treat this round as pattern practice rather than a specific problem link.

Round 4 — Compare Strings by Smallest-Char Frequency

Problem: Given two comma-delimited strings A and B , for each string in B count how many strings in A are "strictly smaller." String X is strictly smaller than string Y when the frequency of the smallest lexicographic character in X is strictly less than the frequency of the smallest lex character in Y.

Two preprocessing passes and one accumulation. First, for each string compute its smallest-character frequency as an integer. Second, sort or bucket-count the A-side frequencies so that for any B-side frequency f you can quickly compute how many A values are strictly less than f . A small counting array of size 11 works because strings are capped at length 10.

The cleanest implementation I wrote on test day: build a length-11 array cnt[] where cnt[k] is the number of A strings with smallest-char frequency exactly k , then compute a prefix-sum array so that less than[f] is the number of A strings with frequency strictly less than f . For each B string, compute its frequency and look up less than[f b] . Linear time in both inputs and O(1) lookup per query.

Application Strategy

A few meta-points that actually helped me:

Apply early. Google's fall cycle opens around July and the OA backlog gets messier as you slide into September. Late applicants I know waited six weeks just for the OA link.

Referrals route your app to a recruiter faster rather than raising your resume bar. If you have no referral, reaching out to alumni on LinkedIn is still worth it because the latency improvement is real.

Match the job keywords on your resume to the specific JD. Google's recruiter-side tooling does skim for exact matches.

Result

Offer came about eight weeks after the OA. L3 new grad, standard package. The OA was a gate, not the main event, but the four problems here were representative of what the platform currently serves, so drill the patterns rather than memorizing the specific statements.

Tips

1. Drill the four-algorithm core: Kadane, binary search on answer, magic-square construction, and smallest-char bucketing. These are the shapes that currently cycle through Google's pool. You can pass without deep DP or graph prep but not without these.
2. Write the input parser first. On the Compare Strings problem I wasted three minutes fumbling the comma split before I realized I should have stubbed the parser in sixty seconds and moved on.
3. Use `bisect` on the Python stdlib for prefix-sum lookups. The Compare Strings solution collapses to five lines if you bucket-count the A side and call `bisect_left` on the B side.
4. If you cannot solve the construction problem, submit the brute force. Magic square with backtracking will pass the small hidden tests and you can still clear the overall OA on the back of the other three.
5. Read the floating-point tolerance on the cake problem carefully. Sixty iterations of halving gives you roughly 18 bits of precision, which is overkill for the stated tolerance but costs nothing.
6. Apply to Google before the backlog starts. Cycle timing matters more than people admit. An early OA is a faster loop, and a faster loop is a less stressful prep window.