Lesson 24 · Senior gRPC backend engineering

Mock senior gRPC interview pack

A retrieval-first practice pack for turning the senior gRPC lessons into interview-ready answers you can say out loud under pressure.

Your win: run a realistic senior gRPC backend mock interview on yourself, score the answers honestly, and turn weak spots into a precise revision list.

In plain English Plain English: answer out loud before checking the answer points. The goal is retrieval strength, not just recognition.

The format

This page works best if you treat it like a real interview, not like a worksheet. Answer first. Then check the points. Then try again more cleanly.

The answer checklist A strong answer should usually include: (1) the mental model, (2) the key trade-off, and (3) a real backend consequence or repo-grounded example. If one of those three pieces is missing, the answer usually sounds thinner than you think.

Round 1 · Core protocol and contracts

These questions test whether the foundation is really yours or whether you only recognise the vocabulary when you see it on the page.

  1. What is the real compatibility rule behind protobuf field numbers?
  2. Why is gRPC built on protobuf plus HTTP/2 rather than just JSON over HTTP/1.1?
  3. What is the practical difference between unary and streaming RPCs?
  4. How do you explain deadlines vs timeouts clearly?
  5. Why are metadata and payload different concepts?
  6. What does a generated stub buy you in practice?
Round 1 · Strong answer points
  1. Field numbers. The field number is the wire identity. Safe evolution preserves existing number meaning, adds new fields additively, and reserves anything removed.
  2. protobuf + HTTP/2. Protobuf gives a strict compact contract; HTTP/2 gives efficient multiplexed transport and native streaming support.
  3. Unary vs streaming. Unary is one request/one response and stays simpler operationally; streaming is for real sequences or long-lived flows and adds lifecycle complexity.
  4. Deadline vs timeout. A deadline is an absolute point in time shared through the call tree; a timeout is just the duration you convert into that deadline.
  5. Metadata. Metadata carries header-like side information such as tokens, trace IDs, and request context; payload messages carry business data.
  6. Stub. The generated stub gives a typed local-looking client API so callers do not hand-build transport details by convention.

Round 2 · Production design and failure modes

This is where the interview starts feeling more senior. The mechanism matters, but the trade-off matters more.

  1. When are retries helpful, and when are they dangerous?
  2. Why can a deadline budget still fail even when every service "supports deadlines"?
  3. Why don’t mature teams expose every internal RPC directly as public gRPC?
  4. When is streaming worth the cost?
  5. What is a strong way to talk about idempotency in RPC design?
  6. What makes an error code mapping strong rather than vague?
Round 2 · Strong answer points
  1. Retries. They help for transient transport failures, but become dangerous when repeating the RPC can repeat a side effect and no idempotency strategy exists.
  2. Deadline budget failure. Teams may propagate the deadline mechanically but still waste the budget through queueing, retries, blocking downstream calls, or handlers that ignore cancellation.
  3. Public exposure. External consumers often benefit from REST/JSON ergonomics, tooling, and compatibility expectations even while internal calls stay native gRPC.
  4. Streaming worth it. When the data truly is a sequence, feed, upload stream, or long-lived conversation; not merely because multiple items exist.
  5. Idempotency. Repeating the same logical request should not create an additional logical effect, which is what makes retries safe enough to consider.
  6. Status mapping. A strong mapping distinguishes bad input, missing permission, transient availability, and real server faults instead of collapsing everything into Internal.

Round 3 · Repo-grounded architecture and debugging

This round is what makes the mock feel specific to your actual backend work instead of generic gRPC trivia.

  1. What is the real codegen workflow in this repo?
  2. How does auth flow through the interceptor chain here?
  3. Why is unary still the normal shape in the three main services?
  4. What does grpc-gateway do in this repo?
  5. What is the senior debugging workflow for a slow or failing RPC?
  6. Why is reflection absent but health present here?
Round 3 · Strong answer points
  1. Codegen workflow. The repo uses raw protoc via make gen-proto-go / proto/gen_go.sh for generated Go and gateway code, while buf is used for lint and breaking checks only.
  2. Auth flow. The auth interceptor reads token metadata, verifies JWT claims, injects claims into context, then authorizes the method against rbacDecider; internal calls can use fake internal JWT context for controlled service-to-service flows.
  3. Unary normal shape. Unary fits the dominant business interactions here and keeps service behavior simpler to reason about and operate; streaming is used only where the sequence really matters elsewhere in the repo.
  4. grpc-gateway. It exposes selected gRPC services as REST/JSON by transcoding HTTP requests into gRPC calls from the same proto contract and mapping auth metadata across the boundary.
  5. Debugging workflow. Identify the exact RPC and symptom, inspect traces/status/metadata/deadlines, locate the relevant interceptor or downstream hop, then fix from evidence instead of assumptions.
  6. Health vs reflection. Health supports operations and probes directly, while reflection is a separate discoverability choice that this repo deliberately does not enable.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off or backend consequence.
3I gave a strong, clear answer with model + trade-off + backend consequence.
Recovery map — where to go next Missed contract and proto answers? Revisit Lessons 2–3 and 18. Missed RPC type and deadline answers? Revisit Lessons 4–10 and 20. Missed interceptor/auth/debugging answers? Revisit Lessons 11–13 and 21. Missed boundary/gateway answers? Revisit Lessons 14–17 and 22. The point is not to reread the whole course; it is to go back to the exact weak seam.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into durable interview recall.
What are the three ingredients of a strong senior gRPC answer?
recall, then click to reveal
A clear mental model, the important trade-off, and the backend or production consequence.
If you want, I can now run this as a live mock senior gRPC interview and grade you answer by answer, the same way a careful interviewer would probe the trade-off behind each answer. Ask me.

Sources. This pack synthesizes the course lessons, especially Lessons 8–17 and 18–23, into retrieval practice.