Google Backend Engineer Interview Questions

I would first compare the new version against the old one and identify which endpoint or code path changed. Then I would profile the service, look at traces and logs, and isolate the hottest function or query. The reason I start with measurements is that performance issues are usually a symptom of a specific hot path, not a general feeling. Once I find the cause, I would fix the algorithm, reduce unnecessary allocations, or add caching if that fits the use case. I would also make sure the fix is covered by a benchmark so the same regression does not come back.

I would think about durability, ordering, retries, visibility timeouts, and how to avoid duplicate execution. If the jobs are long-running, I would also care about acknowledgement semantics so a worker crash does not lose the task. The reason I focus on those properties is that a queue is only useful if it survives failures and supports recovery. I would also ask whether jobs can be processed out of order, because that affects scaling and partitioning. At scale, I would probably want dead-letter handling and monitoring for stuck jobs.

I would first clarify what 'active' means, because it could mean requests, messages, session time, or something else. My default approach would be to stream activity events into an aggregator, keep counts for the current window, and maintain the top 10 with a small heap or ranking structure. The reason I choose a streaming design is that it avoids recomputing everything from scratch every minute. I would also discuss windowing, sharding, and merging partial counts from multiple workers. If freshness matters, I would make sure the aggregation pipeline has low latency.

I would explain that in a distributed system, strong consistency and high availability are often in tension, especially during network partitions. If the system absolutely must stay consistent, some operations may need to fail rather than return stale or conflicting data. If availability matters more, the system may accept temporary inconsistency and reconcile later. The reason I would frame it this way is that the right choice depends on the user impact of a wrong answer versus no answer at all. I would then tie the decision back to the specific product requirement instead of treating it as a purely theoretical question.

I would first measure whether the problem is query latency, too many queries, missing indexes, or connection pool saturation. The easiest wins are usually reducing round trips, fixing a bad query plan, or adding the right index. If the same data is read often, I would also think about caching or precomputation. The reason I start with the database is that backend latency often comes from avoidable access patterns rather than raw compute. I would also mention that I would validate every change with metrics so I know which fix actually helped.