Google Interview Process - Senior Software Engineer

I have ten years’ experience, mostly in backend services and distributed systems. The Google process was virtual, with a recruiter call, technical screen and five onsite interviews spread over two days. I used Python.

Recruiter

We discussed staying hands-on and how my responsibilities had grown. One question was what I owned now that would have been outside my scope three years earlier.

Technical screen

Find the earliest maintenance window lasting D minutes with at least K engineers available at every point. Handovers were allowed.

I merged overlapping intervals for each engineer, then used a sweep line to track coverage. The follow-up required the same engineers throughout. My original solution didn’t cover that, and I didn’t implement the revised version.

Coding 1

Find the fewest-hop route through a directed graph, using at most one emergency link.

I used BFS with both the machine and emergency-link usage in the state. Marking a machine as visited without tracking that allowance could discard a useful route. Follow-ups increased the allowance and introduced weighted edges. This was my strongest coding round.

Related practice: Shortest Path in a Grid with Obstacles Elimination.

Coding 2

Batch consecutive alerts to minimise a fixed sending cost plus waiting penalties, with a limit on batch size.

I initially tried filling each batch. Two alerts arriving far apart broke that approach. I switched to dynamic programming with prefix sums and finished the code, but had little testing time. I implemented batch reconstruction; the maximum-wait follow-up stayed a discussion.

Coding 3

Build a registry supporting updates, removal and highest-priority lookup, excluding expired candidates.

I used a heap and dictionary, with a fresh generation number on each update to identify stale entries. The interviewer pushed on removing and reinserting the same ID, memory growth, and how much cleanup one query might need.

System design

Design configuration rollout and rollback across regions. A useful challenge was a delayed update arriving after a rollback. I gave the rollback a newer rollout sequence pointing to older configuration content. We also discussed regional outages and when a small rollout was safe to expand.

Googleyness and Leadership

“When was your team right to reject your proposal?” led to questions about how I’d made agreement harder. I’d proposed an architecture before understanding the teams’ migration constraints.

My advice: practise changing requirements mid-problem, and prepare examples where you had to change your own approach.