Google OA Interview Experience (2026) - Proctored HackerRank, Word Pattern & Top K Listings, Offer

I set up two hash maps, one from letter to word and one from word to letter, and walked the pattern and the word list in lockstep. The core check is a bijection: if the letter is already mapped, the current word has to equal the mapped word. If the word is already mapped, the current letter has to equal the mapped letter. Otherwise you record both. One early-exit I forgot on my first read-through: if the pattern length and the word count differ, the answer is immediately false. That saved me from a nasty index-out-of-range on a large test case.

Watch out for tricky inputs where the word list has duplicates but the pattern expects distinct letters, and vice versa. I wrote three local test cases before I submitted: abba / dog cat cat dog , aaaa / dog cat cat dog , and a single-letter empty-sentence edge.

The problem is a classical hash-bijection exercise, but Google does not have a dedicated pattern-matcher question in our practice catalog yet. The closest adjacent problem for Google-style hash-map bookkeeping is below.

Round 2 — Top K Frequent Listings

Problem: Given an array of Google Search query IDs, return the k IDs with the highest frequency. If two IDs have the same frequency, return the smaller ID first. The array can be up to 10^5 long and IDs go up to 10^9 .

My approach was a single pass to build a frequency map with a dictionary, then push (−count, id) tuples into a min-heap of size k and pop at the end. The negative count and positive ID gives the right tie-break for free: Python's heap compares tuples lexicographically, so equal-count entries sort by ID ascending. Complexity is O(n log k) time and O(n) space for the counter.

I almost got burned by the tie-break on a hidden test. On my first submission I had sorted by count descending without thinking about the secondary key, and two IDs with the same frequency came out in input order instead of ascending order. Caught it with a quick re-read of the statement in the last ten minutes. This is the class of subtle wording that the Google OA reviewers explicitly score for, and it is worth budgeting two minutes per problem at the end for exactly this kind of re-read.

Round 3 — Merge Booking Intervals

Problem: Given a list of meeting intervals where each entry is [start, end] , merge all overlapping intervals and return the merged list in sorted order. Intervals can number up to 10^4 with endpoints up to 10^9 .

Sort by start, iterate once, and either extend the last merged interval or append a new one. The only decision is whether touching intervals like [1, 5] and [5, 8] count as overlapping. In the HackerRank statement the examples implied inclusive merging, so I treated equal endpoints as overlapping. If the statement had said disjoint, I would have flipped the comparison. Always read the examples, not just the prose.

Runtime is O(n log n) dominated by the sort. I finished this in about twelve minutes and used the remaining time to replay all three problems against three hand-crafted edge inputs each.

Practice it: [[problem/630?company=1|Meeting Rooms III Variant]]

My Strategy Under the Proctor

A few things I did that paid off:

First, I narrated nothing. On non-proctored OAs I sometimes mutter at my screen. On a proctored session that just looks like you are reading answers off another device. Mouth closed, eyes on the editor.

Second, I composed all three solutions inside the HackerRank editor, never in a local file. Paste detection is one of the easiest flags. The editor is not great but it is fine for 150-line submissions, and the penalty for looking suspicious is much worse than the penalty for a clunky workflow.

Third, I submitted test runs constantly. HackerRank's run-against-sample button costs you nothing in the score and it pushes positive signal into the behavioral log. A candidate who submits often and incrementally looks very different in the trace from a candidate who writes in silence for 80 minutes and then drops a complete solution.

Common Pitfalls

• Forgetting to handle empty inputs. In particular, the Top-K problem has to return `[]` when `k = 0` or when the array is empty.
• Missing the tie-break on Top-K. Smaller ID wins, not input order.
• Not sorting intervals before merging. Easy to forget under time pressure.
• Python specifics on HackerRank: the runtime is Python 3, `input().split()` reads a single line, and multiline input needs `sys.stdin`.

Result

I finished with about twelve minutes left and used them to add edge-case tests for all three problems. The result email came nine days later with a phone screen invite. Whatever the proctor recorded, nothing flagged.

Tips

1. Treat the proctor as part of the interview. Google's reviewers look at the trace alongside your submission. A clean behavioral log is worth a measurable amount of partial credit, especially on ambiguous edge cases.
2. Pick the easiest problem first on a 3-problem OA. With only 90 minutes and three problems the cost of getting stuck is brutal. Scan all three in the first two minutes and start with the one whose solution shape you can see immediately.
3. Rehearse `collections.Counter` and `heapq` until they are muscle memory. Google Top-K style problems appear often and the Python stdlib answer is compact enough to write in five minutes if you have typed it a dozen times recently.
4. Re-read every problem statement with five minutes left. The most common reason solid candidates fail the Google OA is missed tie-break rules or off-by-one interpretation in the examples.
5. Never alt-tab. Even to look at the timer. The HackerRank proctor logs every focus loss and the reviewer will see it. Use the in-page timer.
6. Stop at 25 minutes per problem. If you are still flailing, move on. Two near-complete solutions outscore one perfect plus one blank.