← Back to Directory

Google interview notes, page 99 of 215

FAANG / Big Tech

Most of these Google write-ups come from Software Engineers (1,167), then Product Managers (686) and Data Scientists (125). The most reported rounds are the product sense round (667), the technical phone screen (660), the behavioral / leadership round (252) and the onsite coding round (214).

2146 interview notes · updated Oct 2026

Google·Product Manager·Onsite - Product Sense / Strategy

May 2026
Google PM interview with a classic hardware-meets-software curveball: design a refrigerator and forecast year-one sales. The combo of product design and market sizing in one prompt was a lot to juggle.
  • Google is planning to enter the refrigerator market. How would you design the product, and what would your first-year sales estimate look like?

“Two questions stapled together, which I didn't fully appreciate until I was halfway through the design portion and realized I'd burned most of my time.”

View Post

Google·Business Analyst·Onsite - Product Sense / Strategy

May 2026
Google interview with a business strategy case question about launching a restaurant on a corporate campus. Not much else to go on from what was shared, but the question itself was pretty open-ended.
  • If you were setting up a restaurant on a business campus, what steps would you take?

“I blanked for a second because it sounds deceptively simple.”

View Post

Google·Data Scientist·Technical Phone Screen

May 2026
Google DS interview with a product experimentation question centered on Google Maps. One question, pretty open-ended, and it went deeper than I expected once we got into the experiment design details.
  • Google Maps is considering a feature that recommends personalized jogging routes. How would you assess whether this is worth building, and how would you design a launch experiment including success metrics, triggering logic, unit of randomization, guardrails, and minimum detectable effect?

“I spent too long on the 'is it valuable' part and then had to rush through the experiment design, which is clearly the meat of the question.”

View Post

Google·Software Engineer·Technical Phone Screen

May 2026
Google SWE interview with a graph problem that looked like a BFS warmup but had enough wrinkles to slow me down. Not a bad experience, just one of those rounds where you feel like you're one step behind the whole time.
  • You have a graph where nodes are connected by edges. Some nodes are torches that emit power at level 16, and power drops by 1 for each edge traversed. A node's final power level is the maximum it receives from any torch via any path, and anything below 0 means unpowered. Compute the final power level at every node.

“I went straight to single-source BFS and the interviewer just kind of waited.”

View Post

Google·Software Engineer·Onsite - Coding / Algorithms

May 2026
Google SWE coding round with a shuffling algorithm question. Pretty standard stuff on the surface but the implementation details trip you up if you haven't thought about it carefully.
  • Given an integer array representing a deck of cards, implement the Fisher-Yates shuffle algorithm using only a basic random integer generator (no built-in shuffle functions allowed).

“I knew the algorithm conceptually but fumbled the index range on the randint call.”

View Post

Google·Software Engineer·Onsite - Coding / Algorithms

May 2026
Google SWE DSA round that went sideways from what I expected. Prepped for hard DP/graph problems, got a medium sliding-window question instead, and didn't spot the optimal approach until the interviewer nudged me toward it.
  • Design a data structure that tracks a stream of values over time and returns a running metric for a time-based sliding window.

“Spent way too long confused by the time-based aspect.”

View Post

Google·Product Manager·Onsite - Product Sense / Strategy

May 2026
Google product design interview, just one question but it took up the whole session. The kind of prompt that seems easy until you're actually in it.
  • Design a toothbrush for young children.

“My first instinct was to jump straight into features and I had to stop myself.”

View Post

Google·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Google for a software engineer role. The question was a big one: design a full collaborative code notebook service end to end, including execution, proxying, custom JAR uploads, and all the REST API plumbing. Walked away feeling like I covered maybe 70% of what they were looking for.
  • Design a collaborative, editable code notebook service where users can upload custom JAR files with a fully qualified class and method name, submit execution requests with arguments, and retrieve results through a proxy. Define the REST API endpoints and request/response schemas for uploading code, submitting executions, fetching logs and results, and cancelling jobs. Also discuss sandboxing, dependency management, resource limits, concurrency, and result streaming.

“This was a lot to hold in your head at once.”

View Post

Google·Product Manager·Onsite - Product Sense / Strategy

May 2026
PM interview at Google with one product strategy question about estimating infrastructure costs for a major consumer product. Short and a bit disorienting honestly.
  • Estimate how much it costs Google to run Google Photos.

“I went straight into storage costs because that felt obvious, but then realized I was ignoring compute, bandwidth, ML inference for things like face grouping, and the support infrastructure underneath all of it.”

View Post

Google·Software Engineer·Onsite - Coding / Algorithms

May 2026
Google SWE coding round with a graph/relationship tracking problem. The core challenge was handling incremental data, where peer relationships get established before manager info is known, so you have to propagate backwards when new info arrives.
  • Design a system that processes a sequence of employee relationship operations: assigning a manager to an employee, declaring two employees as peers (same manager), and querying whether one employee manages another. The tricky part is that peer relationships can be established before a manager is known, so the system needs to handle incomplete and incrementally updated information.

“The naive approach of just storing direct manager links breaks down fast once you introduce peers.”

View Post