Google — Site Reliability Engineer

This was the recruiter screening for a Site Reliability Engineer role at Google, based in Poland on the Vertex AI team — the group that runs infrastructure for external companies deploying and training their own AI models. It ran about twenty minutes and was entirely in English. No coding, no whiteboard: it is a fit-and-logistics call, and roughly half of it is the recruiter explaining the role rather than asking anything. She spent a long stretch explaining what SRE actually means at Google, and it is worth knowing before you apply. SRE splits into two tracks: systems engineering, which is closer to sysadmin and infrastructure internals, and software engineering, which is the one I was being screened for. The software track wants the same skill set as a general software engineer, but you apply it differently — the systems are always enormous, handling millions of queries per second across Search, Cloud, Gemini, Play and YouTube, and they never stop. Because the code is largely already written, you code far less than in a general software engineering role: she put it at around 20 percent of the day and said explicitly it never reaches 50 percent. The rest is automation, monitoring, optimisation, and on-call incident work — when something breaks you triage it, then do root-cause analysis, write the post-mortem and hand the fix to whoever owns the legacy code, since not everyone has access to all of it. The screening questions themselves were straightforward: location, relocation, visa status, education, what I do day to day, how many hours I actually code. I said three to five hours, which she read back as 50 to 60 percent of my time and seemed happy with. Then language preference (Python, which is what I would take into the interview), whether I use data structures and algorithms regularly, and whether I would be comfortable being tested on them. The production-experience questions were where I had to think. When she asked about supporting production environments I first answered about deploying to AWS and Google Cloud, and she redirected me — she meant monitoring, being on call, being paged for an incident. The concrete example I gave was a database I had deployed where I had left a port open, and an automated bot found it and wiped our data. I had not known that kind of scanning was routine on the open internet. I debugged it, found the cause and fixed it. On distributed systems I described our microservice setup running up to six nodes, and how we queue work across automated workers to absorb the load spike when exam results are calculated every Sunday. The part I got wrong was compensation. She walked me through Google's package first — base, an annual performance bonus at around 16 percent of base that a manager can push to 18 or 20 percent, and equity vesting over four years, front-loaded at roughly 38, 32, 20 and 10 percent and refreshed from year two based on performance. Then she asked for my target. I said 8,000, she asked "8,000 what", and it came out as 8,000 dollars per month. Her response was direct: that is a lot monthly, and "I don't think we're really aligned." I tried to recover by saying I meant net after tax, and she pushed back that the gap would not be 50 percent, so it would be around 6,000 gross, which she still thought was high. I had not actually done the research on Polish market rates before the call, and I said so at the end and asked whether the number could be renegotiated later. She said yes, that was fine. She closed by explaining the process: two stages. Stage one is a single 45-minute technical interview with a site reliability engineer, on Google's own interview platform, where you are given a task and expected to brainstorm approaches, compare trade-offs, pick the optimal one, implement it cleanly, and explain time and space complexity while staying open to feedback. Stage two is three interviews. The whole thing runs one and a half to two months, all remote, all testing data structures, algorithms and programming. She asked for twenty-four hours to sync with the wider team before confirming whether I moved forward. The answer came back as a rejection at this stage.

Practical things worth knowing before a Google recruiter screen: - Know your number before the call. This is the one thing I would change. The compensation question is guaranteed, and answering it badly puts a mark on the conversation you cannot easily remove. I gave a monthly USD figure with no research behind it and the recruiter told me flatly we were not aligned. - Quote annual gross, in local currency. Saying "8,000" without a unit invites the worst possible interpretation. In Europe the default framing is annual gross; a monthly USD figure reads as wildly out of band. - You can walk it back, but do it early. I asked at the very end whether the number could be renegotiated and she said yes without hesitation. If you fumble it, say so in the moment rather than letting it sit. - "Production experience" means on-call, not deployment. My first answer was about deploying to AWS and Google Cloud and it was the wrong answer. They want to know whether you have been paged, triaged a live incident and written the post-mortem. Have one specific incident ready — what broke, how you found it, what you changed. - Have distributed-systems numbers ready. She asked for scale in concrete terms: users, clusters, nodes. Vague answers do not survive that question. - Expect to listen more than you talk. Close to half the call was her explaining SRE. Take it seriously — it tells you the job is roughly 20 percent coding, and if you want to write code all day this is the wrong ladder. - Understand the SRE split before applying. Systems engineering and software engineering are genuinely different jobs. Know which one you applied to. - No technical testing at this stage. No algorithms, no coding. She only asks whether you are comfortable being tested on it later. The technical bar arrives at stage one: 45 minutes, one site reliability engineer, one problem, on Google's own platform.