The Google RRK Interview: Role-Related Knowledge, Explained

What RRK is, and how it differs from GCA

Google's hiring rubric separates how you think from what you know. The GCA round gives you an unfamiliar problem and watches how you reason through it. The RRK round asks whether you can actually do THIS job on day one: the technologies, patterns, and judgment the role demands. For a data role that means data; for a security role, security; for a Forward Deployed Engineer role, it means applied AI, integration architecture, and customer-facing solution work.

In practice the RRK conversation is usually less puzzle-like and more professional: hypothetical scenarios drawn from the job's real work, and deep dives into your own past projects. Interviewers probe depth, not trivia. Being able to name a technology scores nothing; being able to explain when you would choose it, what breaks, and what you did when it broke is the whole game.

What the round looks like for FDE-style roles

For customer-facing engineering roles (Google's Forward Deployed Engineer and adjacent Cloud AI roles are the clearest examples), RRK questions tend to cluster into three shapes:

Ambiguous customer scenarios

A prompt like: a customer wants a vague outcome, walk me through what you would do. The graded behavior is scoping before solving: clarifying the actual problem, stating assumptions, sketching a realistic architecture (often retrieval-augmented generation or a model integration into enterprise systems), and reasoning about trade-offs like latency versus cost or build versus configure. Jumping straight to a solution without scoping is the classic failure mode.

Deep dives on your own projects

Expect several levels of why on work you claim. Strong candidates arrive with three or four prepared stories (a deployment in a messy environment, an integration that fought back, a stakeholder conflict, an incident they owned) and know their numbers: scale, latency, adoption, and outcome. If a story cannot survive three levels of follow-up, do not lead with it.

Domain vocabulary under pressure

For AI-adjacent roles, expect working fluency in the applied stack: retrieval and grounding, evaluation, context windows, fine-tuning versus prompting, and the boring-but-critical enterprise pieces like authentication, data access, and rollout safety. The bar is applied judgment, not research depth: can you connect a business need to a concrete, defensible technical shape.

How to prepare in a week

RRK is a spoken skill, so prepare out loud. Practice decomposing vague prompts daily: take any ambiguous request, spend ten minutes scoping it aloud (who is the user, what does success look like, what are the constraints), then sketch the architecture and name two trade-offs. Rehearse your project stories until the metrics are automatic. Skim the product documentation for the team you are interviewing with, and re-read the job description: the qualifications list is effectively the RRK syllabus.

If the role is FDE-shaped, rehearse the exact blend the round tests. Rung's scenario drills cover the customer-judgment and integration-design calls these interviews probe, and the AI mock interviewer runs the ambiguous case round live, pushes back on your scoping the way a real interviewer does, and debriefs your structure and communication. Practicing that loop a few times turns thinking out loud from a source of anxiety into a habit.