gRPC Interview Questions and Answers (2026)

You’ve probably seen gRPC pop up on job boards and in architecture diagrams lately. It’s not a buzzword; it’s a concrete way to make services talk to each other over HTTP/2 with low latency and strong typing. Below is a set of questions you’ll encounter in a typical interview, grouped by difficulty. After each question you’ll find a short spoken answer (roughly 45‑90 seconds) and a likely follow‑up. Use these as a rehearsal script – you can even run the script through Call Assistant so it can suggest phrasing tweaks while you stay focused on the content.

1. Core Concepts Everyone Should Know

What is gRPC and why does it use protobuf?

Answer: "gRPC is an open‑source RPC framework that lets you define services in a language‑agnostic way using Protocol Buffers. The protobuf schema gives us a compact binary format, which means less payload on the wire and faster serialization compared to JSON. Because the contract lives in a .proto file, both client and server get generated stubs that guarantee type safety at compile time." Follow‑up: "Can you walk me through the steps you take to generate client code from a .proto file?"

How does gRPC differ from traditional REST APIs?

Answer: "REST relies on resources identified by URLs and usually talks JSON over HTTP/1.1. gRPC, on the other hand, treats the whole service as a set of methods and uses HTTP/2 for multiplexed streams, binary payloads, and built‑in flow control. This gives us lower latency and better support for streaming, but it also means we need a protobuf contract and a client that can speak HTTP/2." Follow‑up: "When would you choose REST over gRPC in a production system?"

What are the four RPC types gRPC supports?

Answer: "gRPC supports unary, server‑streaming, client‑streaming, and bidirectional streaming. In a unary call the client sends one request and gets one response. Server‑streaming sends one request and receives a sequence of responses. Client‑streaming works the opposite way, and bidirectional streaming lets both sides send a sequence of messages independently." Follow‑up: "Give me an example of a real‑world use case for bidirectional streaming."

2. Intermediate Topics You’ll Be Tested On

How does gRPC handle authentication and encryption?

Answer: "gRPC builds on HTTP/2, so it inherits TLS for encryption. For authentication you typically use a token‑based scheme – for example, a JWT placed in the authorization metadata header. The server can also enforce mutual TLS, where both client and server present certificates." Follow‑up: "What does the interceptor pattern look like for adding auth metadata in a Go client?"

Explain deadline and cancellation in gRPC.

Answer: "Each RPC carries a deadline in its metadata. The client can set a timeout, and the server will abort processing once that deadline passes. Cancellation works via the same channel – if the client’s context is cancelled, the server receives a cancellation signal and should stop work promptly. This prevents wasted CPU on long‑running calls that the caller no longer cares about." Follow‑up: "How do you propagate a deadline from a front‑end service down to a downstream gRPC call?"

What is a gRPC interceptor and when would you use one?

Answer: "An interceptor is middleware that wraps the execution of an RPC on either the client or server side. You can use it for cross‑cutting concerns like logging, metrics, tracing, or injecting authentication tokens. It lets you keep those concerns out of the business logic." Follow‑up: "Show me a brief code snippet of a server‑side interceptor that logs request latency."

How do you version a gRPC API without breaking existing clients?

Answer: "Because the contract lives in protobuf, you can add new fields with the optional keyword or assign them higher tag numbers. Existing clients will simply ignore unknown fields. If you need to change a method signature, you create a new service or method name and deprecate the old one. The key is to keep backward‑compatible changes in the same .proto file wherever possible." Follow‑up: "What pitfalls should you watch out for when removing a field?"

3. Senior‑Level Design Questions

How would you design a high‑throughput, low‑latency microservice architecture with gRPC?

Answer: "Start with HTTP/2‑enabled load balancers that can perform client‑side load balancing using the grpc.lb_policy name resolver. Keep protobuf messages small and avoid nested structures that cause unnecessary copying. Use server‑streaming for bulk data so the client can start processing early. Deploy services with side‑car proxies (e.g., Envoy) to handle retries, circuit breaking, and observability without touching application code. Finally, enforce deadline propagation and back‑pressure through flow control to keep the system stable under load." Follow‑up: "What monitoring metrics would you expose for each gRPC endpoint?"

Explain how you would migrate an existing REST service to gRPC.

Answer: "First, extract the business logic into a thin service layer that can be called from both REST and gRPC controllers. Write .proto definitions that mirror the existing JSON schema, then generate stubs for the target language. Deploy the gRPC endpoint alongside the REST API behind the same gateway, and gradually route a fraction of traffic to the new stack. Use integration tests to verify parity, then retire the REST routes once confidence is high." Follow‑up: "How do you handle clients that can’t speak HTTP/2 during the migration?"

What are the trade‑offs of using gRPC‑Web in a browser environment?

Answer: "gRPC‑Web translates gRPC calls into standard HTTP/1.1 or HTTP/2 POST requests that browsers can send. It lets you keep the same protobuf contract on the front end, but you lose true streaming – the browser can only receive a single response per request. You also need a proxy (often Envoy) to translate between gRPC‑Web and native gRPC. The benefit is a consistent developer experience across client and server; the downside is added latency and a more complex deployment surface." Follow‑up: "When would you still prefer a traditional REST‑JSON API for a web app?"

4. Sample Answers in Action

Below are three ready‑to‑use answer templates you can adapt to your own experience. Speak them naturally; the goal is to sound confident, not memorized.

Example 1 – Unary Call with Deadline

"In my last project we built a recommendation service that exposed a unary RPC. The client set a 200 ms deadline because the UI needed a response before the spinner disappeared. On the server we wrapped the handler with a deadline interceptor that logged a warning if the processing time exceeded 150 ms. This kept the error rate under 2 % and gave the front end a smooth experience." Possible follow‑up: "How did you test that the deadline handling behaved correctly under load?"

Example 2 – Bidirectional Streaming for Real‑Time Chat

"We used bidirectional streaming to power a live‑chat feature. Each client opened a stream and sent messages as they typed. The server broadcast each incoming message to all other streams, leveraging gRPC’s flow‑control to avoid overwhelming slow clients. Because the payload was protobuf, the per‑message overhead was under 1 KB, which let us sustain over 10 k concurrent connections on a single VM." Possible follow‑up: "What back‑pressure mechanism did you rely on when a client fell behind?"

Example 3 – Migration from REST to gRPC

"When we migrated our payment API from REST to gRPC, we first generated stubs from the existing OpenAPI spec, then wrote .proto files that matched the JSON schema. We kept both endpoints live behind an API gateway and routed 10 % of traffic to gRPC for a month. Automated contract tests ensured the responses were identical. After the trial, we cut the REST path and reduced average latency from 120 ms to 45 ms." Possible follow‑up: "Did you encounter any issues with client libraries that only supported JSON?"

5. Common Pitfalls and How to Avoid Them

6. Tools and Practices for Mastery

• Write a .proto file from scratch: Pick a simple domain (e.g., a todo list) and generate client/server code in your language of choice.
• Run a local Envoy proxy: Observe how gRPC‑Web translates calls and experiment with retry policies.
• Instrument latency: Add interceptors that emit Prometheus metrics and visualize them in Grafana.
• Practice aloud: Use Call Assistant to record yourself answering a question, then replay to catch filler words and tighten the narrative.

How to practice this

1. Flashcard drill: Create a card for each question above. Say the answer out loud in 45‑90 seconds, then check the template.
2. Mock interview: Pair with a colleague and take turns being the interviewer. Use the follow‑up prompts to keep the conversation natural.
3. Code‑first rehearsal: Implement a tiny gRPC service that covers unary, server‑streaming, and bidirectional streaming. Explain each step as if you were describing it to a non‑technical stakeholder.

---

FAQ

• Q: Do I need to learn both HTTP/1.1 and HTTP/2 to use gRPC? A: gRPC runs on HTTP/2, so you should understand the basics of HTTP/2 (multiplexing, flow control). Knowledge of HTTP/1.1 is useful for legacy integrations but not required for core gRPC work.
• Q: Can gRPC work across different programming languages? A: Yes. Because the contract lives in protobuf, you can generate client and server stubs for dozens of languages, ensuring type‑safe communication across heterogeneous stacks.
• Q: Is gRPC suitable for public APIs? A: It can be, but you need to consider tooling support for browsers and the need for HTTP/2. Many companies expose gRPC‑Web endpoints for public consumption, or they keep a REST façade for broader compatibility.
• Q: How does gRPC handle versioning compared to REST? A: Protobuf’s field numbers and optional fields make it easy to add new data without breaking old clients. In REST you often need URL versioning or careful schema evolution, which can be more disruptive.