Google SRE Interview Experience — Coding, Networking, and a Distributed Rate Limiter

I interviewed for a Google SRE position a few days ago. The overall difficulty wasn't especially algorithm-heavy — it leaned more toward system design, real-world troubleshooting, and coding.

Interview content

1. Coding (LeetCode style)

   • They asked a string-processing question: given a log file where each line is "timestamp, user, action," count the number of sessions per user.
   • It was a variant of "grouping + sliding window." I wrote it in Python, and the interviewer followed up asking about time complexity and how to optimize it.

2. Linux & Networking

   • They asked a few troubleshooting questions:
   • What do you do if CPU usage on a machine spikes?
   • If service latency is high, how do you use netstat / tcpdump / traceroute to investigate?
   • They asked about the DNS resolution process, and the difference between dig and nslookup.

3. SRE concepts

   • Explain the difference between SLI / SLO / SLA, and they gave a scenario for me to set a reasonable error budget.
   • They asked how to design a monitoring and alerting system, and how to avoid alert fatigue.

4. Distributed system troubleshooting

   • A classic question: a distributed database has data inconsistency — what are the possible causes and how would you investigate?
   • My answer covered replication lag, leader election, clock skew, network partitions, and so on.

5. Design a simple rate limiter to make sure API calls don't exceed a QPS limit.

   • I gave two approaches:
   • Token bucket algorithm
   • Sliding window
   • The interviewer kept following up, asking how to make it consistent in a distributed environment, and so on.